I'm writing a Win32 service in C++. I have a custom Assert macro that calls DebugBreak() (among other things). When I'm running my service under Vista, the service crashes when reaching the DebugBreak() call (an int 3 assembler opcode), showing the vista crash dialog. The error code is 80000003 (hardcoded breakpoint).
Normally I'm expecting that my service runs over the DebugBreak() call without doing anyting when no debugger is attached. Why is it crashing? Is there a possible setting to change so that it continues to run?
It is crashing because it is a breakpoint exception.
To be on the safe side you need to either check if a debugger is attached:
if(::IsDebuggerPresent()) ::DebugBreak();
or use try/except and return 1 (exceptionexecutehandler with an empty handler) for your breakpoint exception from the filter.
Normally I'm expecting that my service runs over the DebugBreak() call without doing anyting when no debugger is attached. Why is it crashing?
The MSDN Help for the DebugBreak function says, "If the process is not being debugged, the function uses the search logic of a standard exception handler. In most cases, this causes the calling process to terminate because of an unhandled breakpoint exception."
Is there a possible setting to change so that it continues to run?
You could try adding a Structured Exception Handler.
Alternatively, check some run-time flag before calling DebugBreak.
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 just came across odd behavior with exception handling in .Net. (I'm using C# in MS Visual Studio 2008, but one question I saw here seemed to imply that what I see is true throughout the .Net world.) I am writing a plain WinForm application. I am intentionally causing an unhandled exception to be thrown inside a form_load event handler, outside of any try block. I get no notification. If an unhandled exception occurs in a normal method, a message pops up telling me that the exception happened, and giving me some information about the problem. But in the handler, the code just quietly exits the function without letting anybody know that it happened. If I add a try/catch block, the exception is caught as expected.
Is it true that this behavior happens in all event handlers? And is this expected behavior? And if so, is it because there is too much danger of bad things happening if an event handler unexpectedly stops?
Whether inside or outside VS, this behavior occurs when there is a debugger attached to the process. However, being a debug version makes no difference. If running outside VS without a debugger attached, the unhandled exception will fire up.
You can check
Why the form load can't catch exception? , and
VS2010 does not show unhandled exception message in a WinForms Application on a 64-bit version of Windows , for possible solutions.
EDIT: This behavior is only specific to the form_load event handler, as far as I know.
I've assembled my new PC yesterday, and I've decided to give Windows 8 a try. However, today, during the debugging of moderate Qt application, debugger yielded "Invalid Binding Handle" error message on a pretty simple line (it was line that is auto-generated by Qt's moc.exe:
// QWebView *view (...)
view->setUrl(QUrl(QString::fromUtf8("about:blank")));
// Failing in setUrl call, not in QUrl constructor, or in fromUtf8 function.
However, running this application without debugger works just fine, both in Release and Debug versions.
I've got some clues on the internet to enable Terminal Services, but it seems that there is no such service in Windows 8.
Does anybody have any clue what should I check?
Edit
Moving the widget into other application yielded no error, so apparently, widget (which is pretty small - just QWebView and QProgressBar) is fine. But, when I show this widget in my main function:
QApplication app(argc, argv);
MyWidget w;
w.show();
return app.exec();
it is still failing with the same error. Examining call stack (which is not very helpful when error appear) and stepping into function calls, I've tracked error down to retval = HeapFree(_crtheap, 0, pBlock); in function _free_base, in file free.c And it seems that function is called from dbgdel.cpp, function _free_dbg( pUserData, pHead->nBlockUse ); and it is called from unlock() function.
Attaching the debugger to already active process is still yielding the same error.
I am linking a lot of 3rd party libraries here, so I will try without them, as I'm run out of ideas...
Edit 2:
If I pass this exception to the program, it seems to be running fine.
Edit 3
Commenting setUrl line raises the same exception somewhere in QWebKit, where strdup function is called...
Well, this was easy, but it took me two months to solve (while ignoring the error in the meantime).
This was not an unhandled exception - this was handled exception, and stepping into assembly code and watching the stack frame told me that this exception was handled.
Then I remembered that I've set debugger to break when all C++ and Win32 exceptions are raised. Resetting the debugger settings removed the issue.
My vs2010 shows this message when an exception is thrown:
How can I configure the debugger to show exceptions like this instead:
Thanks!
Big difference between the two. You'll only see the first one when you explicitly configure the debugger to stop when an exception is thrown. You do so with Debug + Exceptions, Thrown checkbox. You don't often use this, really only when your code contains too many catch statements that swallow exceptions inappropriately and making the code misbehave. It also has a knack for showing exceptions in code you didn't write. Click the Break button to allow the debugger to show you the details.
You'll only get the second screenshot when an exception is thrown and there is no catch block to catch it, making it an unhandled exception. That's a fatal error, the program cannot continue. The debugger stops to show you the problem, it is otherwise the end of the debugging session. Without a debugger your program will crash. This is the 'good' kind, you get it by omitting try/catch blocks so your program terminates when something unexpected happens. You will want to write an event handler for the AppDomain.CurrentDomain.UnhandledException event so the user at least has an idea what went wrong. And you for that matter.
I am trying to launch an application via the ShellExecute() API call. This application contains only a main function which does some processing and exits.
Now I have put DebugBreak() in starting of main. When ShellExecute() is called the application is launched successfully but it does not ask for breaking.
How can I debug my application when launched from other application using ShellExecute()?
I am using VC++ .
If DebugBreak() isn't workign for you, try _CrtDbgBreak(). Note that _CrtDbgBreak only works in a debug build.
_CrtDebugBreak definitely works for me to make a launched process break on startup, although I'm pretty sure DebugBreak does also.
Note that both functions will make it look like the process has crashed, since they raise an exception. That is normal and gives you the opportunity to attach a debugger via the crash dialog. (The crash dialog also lets you terminate the process; don't use that, obviously.)
Also note that if you have a catch-all SEH exception handler around your main then the exception raise by DebugBreak & friends will be swallowed up and the app will simply exit without showing the crash dialog or letting you attach to it.
You can't do this with VC++; with WinDbg this is just .childdbg 1 to debug all child processes. With VC++, you can use Image File Execution Options in a pinch - check out http://codereflect.com/2009/09/20/how-to-debug-child-process-using-windbgvisual-studio/ for more info. Really though, if you've got the time to learn WinDbg, it's much better at this.
you can try this, it's ok in xp system.
app.exe is your application name,
-s1...-s3 is command line arguments.
HINSTANCE hRet = ShellExecute(NULL, L"open", L"vsjitdebugger.exe", L" app.exe -s1 a1 -s2 a2 a3 -s3", szExePath, SW_SHOW);
There is now a Microsoft Child Process Debugging Power Tool.
The method I use for things like this is to embed some interactive code, which you can either delete afterwards, comment out or conditionally enable. In a few cases we have this code enabled by querying an environment variable which is set by the tool that launches the main application. This allows me to click a check box, hit launch and have the breakpoint dialog in seconds.
if (MessageBox(NULL,
_T("Attach the debugger now, then choose Yes to hit a breakpoint"),
_T("Attach Debugger"),
MB_YESNO) == IDYES)
__debugbreak();
This gives you the ability to attach the debugger when the dialog box appears and the option to hit a breakpoint or not. My earlier versions didn't give me the option and after a while I realised some of the time I wanted the breakpoint, and some of the time I didn't.