Need to call the debugger when an app gets loaded

RchdR · July 20, 2025, 10:07pm

I’ve written a browser extension which calls a clarion app, but I cant tell for sure what the string data encoding is thats passed to the clarion app’s console window.

The browser passes UTF8, and obviously Clarion is ansi, so I suspect its UTF8 going into the clarion app’s console window, but I want to see the individual bytes thats sent to the clarion console windows buffer and I dont know how I can get the clarion app, to load the debugger and run the debugger.

Any ideas?

TIA.

jslarve · July 21, 2025, 12:26am

you can pass the processID with -p

jslarve · July 21, 2025, 12:29am

There’s a non-elevated version of the debugger. I think it’s cladbne.exe, but I’m not at my Clarion machine.

RchdR · July 21, 2025, 7:22am

OK, I’ll check out those suggestions. Its more for piece of mind, seeing the console buffer with UTF8 data in the debugger, but I want to see if anything else is being passed to the console, and what else I could slip in there, ie exploring its limits.

Javascript has come along way.

Edit.

So I’ve got

!Call Debugger when App gets called 
Glo:CurrentPID = ISWA_GetCurrentProcessId(0)
!Message('Glo:CurrentPID = ' & Glo:CurrentPID)
!Run('C:\Clarion11\bin\Cladbne.exe -p ' & Glo:CurrentPID, 0)

it loads the debugger but doesnt load or hook the app in. I’ve copied the red file into the folder in question as well.

Any suggestions?

TIA

RchdR · July 21, 2025, 5:12pm

Surprisingly its Ansi!

jslarve · July 21, 2025, 9:18pm

With UTF8, it can look like ANSI until you introduce extended characters

RchdR · July 22, 2025, 11:50am

I changed each buffer byte to a VAL and there’s no second byte to make a unicode char, so I’m guessing the console window has changed it ANSI.

jslarve · July 22, 2025, 2:26pm

OK, but that does not negate what I said. I’m not saying you’re wrong about the console buffer, but I don’t know that you are correct, either. Try passing something with a unicode character on the command line. If there are 2 or more bytes comprising that character, but everything else “looks” like ANSI, then that looks like UTF8

jslarve · July 22, 2025, 2:45pm

This screenshot from the Wikipedia page on utf8 shows how, by looking at the first byte, it knows whether it’s a 1,2,3, or 4 byte character. If bit 10000000b is turned on, then it will be at least 2 bytes.

RchdR · July 22, 2025, 3:38pm

Ok, I’ll track down a webaddress which is made of unicode characters and see what gets passed.

Domain names are primarily based on ASCII, but can also utilize Unicode through a system called Internationalized Domain Names (IDNs). While the core DNS system operates on ASCII, IDNs allow for the use of characters from various languages and scripts, encoded using Unicode. These IDNs are then converted to an ASCII-compatible format called Punycode for use within the DNS

I’m just passing the web address to the console window at this stage, to create a browser extension which can communicate with a clarion app.

Bruce · July 22, 2025, 6:42pm

Richard, the important detail here is that theres no such thing as a unicode string.

Unicode is a mapping, not an encoding. Clearly your string is not utf-16 but it could be utf-8 or ansi.

To test if its Ansi or utf-8 you’ll need to inject a character which is encoded differently between those 2.

RchdR · July 22, 2025, 7:45pm

I will, but I already have the MultiByteToWideChar and WideCharToMultiByte working and ready in place to handle the conversion to Ansi CP-1252.

RchdR · July 22, 2025, 8:16pm

Next step to try is to attach the debugger running PrjServer.exe process:

Find the PID of PrjServer.exe in the Process Explorer

Find the TID of the thread that eats the CPU time

Run

 cladb -p <pid>

In the debugger open the Thread List window (main menu → Window → Thread List)

Highlight the line for the thread with found TID

Press the Ctrl-Space key to suspend selected thread and the press the Space key to show that thread’s in the Stack Trace window

Right click on the most bottom upper-level node in the Stack Trace window and choose the Locate In Assembler item in the popup menu

Make the height of the disassembler window as much as possible and provide the screenshot.

CODE
    !Run('"C:\Clarion11\bin\Cladbne.exe"', 0) ! Loads Cladb
    Glo:CurrentPID = ISWA_GetCurrentProcessId(0)
    Message('Glo:CurrentPID = ' & Glo:CurrentPID)
    Glo:DebuggerCommandLine = '"C:\Clarion11\bin\Cladbne.exe" -p ' & Glo:CurrentPID
    Run(Glo:DebuggerCommandLine, 0) ! Does not "appear" to work
    Glo:DebuggerCommandLine = '"C:\Clarion11\bin\Cladb.exe" -p ' & Glo:CurrentPID
    Run(Glo:DebuggerCommandLine, 0) ! Works - Well you get the UAC prompt, but then ClaDB dissappears - Windows Defender possibly?
    !Run('"C:\Clarion11\bin\Cladbne.exe -p ' & Glo:CurrentPID & '"', 0) ! Does not "appear" to work
    !Run('"C:\Clarion11\bin\Cladbne.exe"', 0) ! Does not "appear" to work
    !Run('"C:\Clarion11\bin\Cladbne.exe" -p' & Glo:CurrentPID, 0) ! Does not "appear" to work
    Main()

Edit.

Bruce · July 22, 2025, 10:14pm

In this context the term “multiByte” refers to utf-16. So those functions are appropriate for converting utf-16 to and from ANSI.

If the text you are receiving is utf-8 then those functions are not in play, and the string would not be described as a “wide string”.

Frankly, I don’t think your text is utf-8. I think it is most likely ANSI. So I suspect this trip down the rabbit hole is unnecessary.

RchdR · July 23, 2025, 7:49am

Well I’ve now found out what the first 4 bytes of data were thats sent to the console before I extract the data out. Its inconsistency was throwing me, namely sometimes I was only getting 0000 and other times I was getting a value to indicate the length of the data, but the browser webNavigation event model may influence when this leading 4 bytes works properly.

Each message is serialized using JSON, UTF-8 encoded and is preceded with an unsigned 32-bit value containing the message length in native byte order.

The maximum size of a single message from the application is 1 MB. The maximum size of a message sent to the application is 4 GB.

The application stays running until the extension calls Port.disconnect() or the page that connected to it is closed.

In the context of running the debugger cladb.exe -p <ProcessId> from the app after the browser has called it, it looks like I need to spawn a new process.

On Windows, the browser puts the native application’s process into a Job object and kills the job. If the native application launches additional processes and wants them to remain open after the native application is killed, then the native application must launch the additional process with the CREATE_BREAKAWAY_FROM_JOB flag, such as by using CreateProcess.

I will say, Connectionless messaging is not a very efficient way to communicate, it start a new instance of the EXE every time a message is posted to the console window for each tab open and each event I’ve add a listener to. So I’m looking at alternative ways to capture the messages namely Connection-based messaging and using a mutex in the clarion app to prevent multiple instances of the app.

The console window appearing when using allocConsole is also a deal breaker, but CreateFileA should be the work around I’m looking for in order to gain some stealth.

Just need to implement those changes as v2.

RchdR · July 25, 2025, 9:32pm

sometimes a picture speaks a thousand words.