Still very strange.
According to the messages that Windows sends to the debugger, the debugged app exited without any error (errorcode = 0).
This happens within 1 second from when you tried to continue with F9.
v1 is the log saved when the "freezing" happened
About "freezing", from the log it looks like the debugger stopped "normally" (well, ignoring that it shouldn't stop...).
That is, it should behave as if the app just exited.
I take it, that you probably disabled "show message on stop" from "tools > options > debugger > general".
So you don't get the message box "Execution stopped".
==> You should however see that the red stop-button gets disabled (greyed), and the green-start button enabled again?So if you say "freeze" what exactly does that describe?
- What are the states of the debugger tool buttons?
- What does the caption of the IDE title-bar say (does it still say "debugging")?
- If, it is stopped, can it be started again with F9 or Run?
(Note, if you press F8 while the debugger is stopped, then the debugger will hang)
Depending on whether the debugger "stops" or "freezes", there are one or two issues.
- Issue 1: your app terminates, when it certainly should not
- Issue 2: the debugger hangs
About the "your app terminates".
This could be some issue with Windows11 or your VM.
It could be Windows Defender too.
Under Windows-10 there is "Windows security" > "Virus and thread protection" on that page "manage settings" => "virus and thread protection settings":
A lot of on/off switches, and at the bottom of the page "Exclusions" / "Add or remove exclusions"
Add both, the IDE, and the debugged app.
There is a bit of a "chicken and egg" issue with all the "access denied" in the logfile.
I can't tell, if they (all/some of them) are a consequence of your app terminating or if some of them are causing (indirectly, via fpdebug) your app to terminate.
Though in the latter case, I would not expect "error code = 0"
EVENT for Process 26848 Thread 26740: << EXIT_THREAD_DEBUG_EVENT exitcode:0 True
EVENT for Process 26848 Thread 13200: << EXIT_PROCESS_DEBUG_EVENT exitcode:0 True
There is one test you could do.
components\fpdebug\fpdbgwinclasses.pas
line 1600
procedure TDbgWinThread.Suspend;
...
procedure TDbgWinThread.Resume;
In both procedures insert an "exit;" as very first statement. So both functions will exit without doing anything at all.
Then FpDebug will no longer try to disable a thread that has exited. In case this somehow causes more other threads to exit.
It is possible that some of the threads are valid to exit at those time. This could be threads the OS added, and they are expected to terminate at some time.
F8 while the debugger is stoppedFpDebug can only be started with F9/Run.
However the IDE does not obey that, and will send an F8 (in order to start debugging / as gdb does accept this).
In that case, FpDebug does not start, but the IDE believe it is running => only "reset debugger" will work.
Btw, while not ideal, but you can still use gdb and at least be able to debug (unless gdb has the same issue).
Tools > Options > Debugger Backend
Also can you please confirm: Your IDE is 64bit and your are cross debugging to 32bit? (Which should work)