I'm trying to figure out what my debugger does when I hit the pause button, so I decided to hook the WM_LBUTTONUP message (by inserting my own code after PeekMessageW and hitting an int3 if the message is equal to 0x202) so that I can see what commands run after that and how it differs from other messages/no message.
Unfortunately there appears to be no significant change in the code path, as it appears to just run "the message loop" either way and I can't find out how to get to where "LRESULT CALLBACK WindowProcedure()" would normally be if I were looking at the code in C/C++. How do I get to that portion of the code in my debugger?
Related
Using UI Automation for some Windows I get the following exceptions on a IUIAutomationElement::FindAll() call using VS2017. First question, what is a wil:ResultException and what does it mean it rethrow at memory address 0? I check the FindAll() result and doesn't seem to have FAILED(hr) because it outputs a debug message if it did and it's not.
Exception thrown at 0x00007FF897AC3E49 in app.exe: Microsoft C++ exception: wil::ResultException at memory location 0x000000550AF2BDC0.
Exception thrown at 0x00007FF897AC3E49 in app.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
I don't know if it is related or not. I turned on the fairly new "Use Text cursor indicator" as users are telling us our app can crash when it is on. After doing some testing, I was closing the app and got an access violation deep in UIAutomation.dll. The system was just exiting the process. I was trying to duplicate the crash and though I didn't crash, I just saw this same message and the reply to this post that mentioned UIAutomation. The "fairly" new setting is new to me because our IT just allowed the version update that has the setting on our boxes.
The crash occurred while doing a PeekMessage during the exit of the process. We had a static c++ object that was being deleted and during that call, it called the API. I rearranged the code to make the call that used PeekMessage so it happened before the process exited. That avoided that crash. However, we are MFC based and in a debug build, if any code does an ASSERT during shutdown, MFC's assert code does a PeekMessage to remove WM_QUIT before showing the assert message box. So, we can still crash there randomly in our debug builds.
When running with the Text Cursor Indicator on, I see a lot of these "wil" exceptions in the debug output window (release or debug builds). Many seem to occur when a window that has the indicator drawn over it closes. Example - standard file open dialog. I open it, click the path edit box and when I close the dialog, I get some of those exceptions. Turning off the indicator setting avoids all of that and the crashes.
I am writing my own debugger in VS code for a custom language. Everything works fine, when I click "step over" my program is being debugged correctly, but I cannot see anything in the editor. I think the problem is the "stoppedOnStep" event, I followed the tutorial here: https://code.visualstudio.com/api/extension-guides/debugger-extension but there is no way to send line number or file name in the "stopped" events.
Here is the event in the code example: this.sendEvent(new StoppedEvent('step', MockDebugSession.THREAD_ID)); and as you can see, no info on file name of line number, so I have no idea how that part of the debugger works. How does the debugger client know on which line is the program stopped? Is there some secret getLine() method that reads the line number from the runtime?
Turns out the answer is in the stack trace. After the stopOnStep event (or any other event), the editor sends a stack trace request to the debugger, and the last entry is the current line of the execution.
I have found in my company's codebase a code to open default mail program using ShellExecute. The code is written long time ago, but I've notice strange behavior on it, the problem only occurs when the debugger is not attached.
if ShellExecute(Handle, PChar('open'), PChar('mailto:donotreply#nonono.com'), nil, nil, SW_SHOWDEFAULT) <= 32 then
begin
//...
end;
Above is the relevant part of the code. Handle is the Form handle.
To reproduce the problem, simply create a new project, add a button on it and call this code on the button onClick event handler. It is also necessary to not have a default mail installed, so windows will display an message warning about that.
When debugging, the message Z order is higher than the application, so the message box is properly displayed and the user can close this message.
When not debugging, the message Z order is lower than the application, so the user has to alt+tab to see that message.
I don't have enough knowledge to understand what is happening nor to state if that behavior is correct or not.
Is there anything I can do to properly display the message box in a higher Z order than my application?
Is this code deprecated? Should I move forward to a different way of doing this, if so, how?
I am writing a Google Chrome extension. One of my content scripts has a little bug that I can't find and the Google Chrome debugger appears to be useless for this purpose. The code stops on an Uncaught typeError: Cannot set property 'value' of null. I can see this by opening the debugger and viewing the console after the code fails. But my content script does not appear in the list of scripts shown in the debugger at this point. There are a lot of scripts shown there, including a big block of scripts in light blue. But none named "profile.js" which is my content script.
I tried "location.reload(); but it simply returns "undefined." I'd love to step thru this code and find the problem but I can't figure out how to do it. I've set alerts to try to track the problem but once I click on the alert, the script continues with no opportunity to invoke the debugger. Based on the result of the alert experiment, it appears the code is failing at the very end. I presume the code is finished by the time the error is caught and the script is no longer available to the debugger.
I tried adding this line to the script: "debugger;" to try and force the debugger to open but there is no change whatever to the execution of the code. It fails as usual and as usual I can open the debugger, find the console message and the big list of scripts that does not include mine.
How can I pause execution of the code using a line in the code itself? I just want to stop execution of the code at the beginning, invoke the debugger, set up some breakpoints, resume execution and monitor some variables. That seems like a pretty simple and do-able request.
Any ideas?
Here's the problem: The main GUI thread is performing a SendMessage to another GUI thread (yes, there are multiple GUI threads, and unfortunately this cannot change). When that second GUI thread receives the SendMessage, it may decide to display a message box. Some of the time, that MessageBox will 'freeze' the entire application.
More specifically, the message box shows up, but the entire GUI is hung (user input does not work anywhere).
I've verified with a debugger that the second GUI thread is spinning in the DialogBox2() function defined in user32.dll. I can see in the disassembly that a message pump is being executed (I see IsDialogMessage/TranslateMessage/DispatchMessage being called). Using spy++, I do not see any messages being processed for the message dialog box window. I do see messages getting processed on the main GUI window (such as WM_SETCURSOR, though I do not thin they are being processed as I believe SendMessage doesn't execute a message pump).
The second thread is executing code that is part of an MFC extension DLL, if that matters.
I've tried using AfxMessageBox() / CWnd::MessageBox / ::MessageBox(NULL parent window,...). All exhibit the same problem.
Has anyone seen anything similar before?
Thanks,
Andrew
It must be that blocking one of the GUI threads causes the problem.
Try this:
Replace the ::SendMesage with ::PostMessage followed by a ::MsgWaitForMultipleObjects loop. You will need to pass an event handle that signals when the message box is closed.
It will probably solve the problem.
Just be careful which messages you dispatch in you ::MsgWaitForMultipleObjects loop.