Debugger, Windows 10, and the case of the dissappearing debugged app

General
1

I had to slog back into Xojo 19r3.2 today to check an issue that’s being reported on Windows 10 latest. I used the traceback from the user to set breakpoints, started the debug run, duplicated his steps and got to my first breakpoint. I then stepped into the called method, made sure the processed values were correct, and then clicked continue. This ran to my second breakpoint and stopped. I then clicked next, next, next - and poof - my app was gone and the IDE was dropped into the run loop as if all was well.

Okay, I must have mis-clicked …

Exited and relaunched the IDE, set things up and reran the same steps as above - this time, it poofed after the first “next” following the second breakpoint.

So reassuring …nothing in the syslog nor the messages pane.

Of course, I was ignorant enough to move this one project up to 19r3.2, so I can’t try another version of the IDE.

1 Like
2

Have you tried the steps in both 32bit and 64bit? Does the same thing happen?

3

debugging 64 bit anything is hell
I’ve got several reports marked reproducible about debugging issues
Skipping break points, jumps in and out of code as you step, etc
I guess Ive lucked out and NOT had the exe just disappear - yet :slight_smile:

4

The bug doesn’t occur in the 32bit version … :rage:

5

Both the users bug and the ide bug don’t occur?

6

Checked windows defender folder access?

7

Right - The user’s reported issue doesn’t occur and the IDE doesn’t lose the debugged app.

8

Yes - and I also thought that it might be a UAC gotcha, but neither are the culprit.

9

Do you use any windows declares?

10

Nope - not in this project, not even MBS - bare bones Xojo code with Einhugur’s WindowSplitter.

11

There is nothing left in the messages section, either (I use the Syslog functions).

NoMessagesEither
NoMessagesEither2317×1073 42.4 KB

12

Ahh you are actually not seing your app launch or your window coming up??
We have had this once, it happened when we had 2 instances of the main window being shown (or at least being re-instantiated and called .show of that window).

This made it so the window actually never showed up (in windows).

13

Make sure you have an active DefaultWindow selected and have it implictinstance = true (from the ide)

14

No, the app has been running for around 2 hours to get to this point. And, the messages window was loaded prior to the app “poofing” on me.

15

So it was running 2 hours then the main window disapeared?
Does the taskmanager show the process running ?

16

Right. It breaks at the first breakpoint, I step through the method and then run to the 2nd breakpoint. I then start stepping the the label.Text setting steps and that’s when it goes away.

As mentioned above, it doesn’t exhibit the error that I’m chasing in 32bit more, but the customer is a Government agency that no longer accepts 32bit apps of any type.

17

I dont think System.Log is intercepted in the same way System.Debuglog is to be shown in the message area

Like you I’ve had no end of issues trying to debug in 64 bit (macOS or Windows)
I’ve resorted to “printf style debugging” many times calling the respective OS API not Xojo’s logging methods

18

Does it happen to change threads if this is possible you should be able to change the thread context in the debugger perhaps? I’ve seen this behaviour in windows 64 bit builds also but can’t really remember how we came trough.

19

Mistyped on my end - System.DebugLog is used. From my Debug.Pring method:

Dim d As New Date
If RightB(sDebug, 1) <> EndOfLine Then
  sDebug = sDebug + EndOfLine
End If
theOutput = theOutput + d.SQLDateTime + ":" + Space(DebugIndentLevel * 2) + sDebug
System.DebugLog(theOutput)
20

No threads in this one.