views:

57

answers:

1

I have a mixed-mode application in which I want to fire up the debugger if an error is found in the internal datastructures. Strange enough, the DebugBreak and __debugbreak functions don't seem to work as expected (the .Net framework seems to intercept the breakpoint exception, leading to all kinds of nasty side effects).

The solution of my earlier question (see http://stackoverflow.com/questions/3629783/behavior-of-debugbreak-differs-between-unmanaged-and-mixed-unmanagedmanaged-ap) seems to work for very simple situations, but not in my application (it just leaves my application hanging).

Luckily, I found out that executing System::Diagnostics::Debugger::Launch seems to solve the problem. However, the place where I need to have this logic is used in both unmanaged as in mixed-mode applications. Also, calling managed code in the place where I want to put the logic is rather difficult.

Therefore: is there an unmanaged alternative for the System::Diagnostics::Debugger::Launch function?

+1  A: 

It seems to me that the usage of System::Diagnostics::Debugger::Launch is a good point. .NET Debugger like some other .NET classes has also unmanaged interface for example ICorDebug::DebugActiveProcess. It seem to me you should try to use it. You can read more about this in http://msdn.microsoft.com/en-us/magazine/cc301510.aspx. It is will not work, that you can try to write you own small COM interface in .NET with one method only which call System::Diagnostics::Debugger::Launch.

Another ways is the usage Just-In-Time Debugging and How to: Launch the Debugger Automatically.

If you don't need to debug the startup code of your application you can do what you want in very simple way: At the beginning of your application in the main thread (or in all threads which you want to debug) you can display a message box. After you see the message box you can start Visual Studio as Administrator and use "Debug" / "Attach to Process...". It works very good. If you want to debug a Windows Service you should use WTSSendMessage instead of MessageBox. I am using this way since many years and it work perfect.

Oleg
Unfortunately, I read this on the ICorDebug::DebugActiveProcess page: Interop debugging is not supported on Win9x and non-x86 platforms, such as IA-64-based and AMD64-based platforms.And yes, I have to support x64. Nevertheless, good tip.
Patrick
@Patrick: Do you generate code for x64/IA-64 or it will run as WOW on 64-bit? For WOW Interop debugging should still work. Suppurt of Win9x system seems me not really needed or is it important for you?
Oleg
@Patrick: Moreover I don't exactly understand the situation where you plan to start fire up the debugge from the application. Is IntelliTrace debugging (see http://msdn.microsoft.com/en-us/library/dd264954.aspx) is not what can help you?
Oleg
@Oleg, yes my application can be compiled as a x64 application (I have some customers with really huge datasets, requiring about 10GB in memory). Firing up the debugger is needed if the developers notices an assert, and he wants to jump into the debugger to look at the problem (and also being able to continue running the app in the debugger). At this moment the only workable and simple solution seems to be the MessageBox approach (which was also given by you). So I think I'll stick to that solution.
Patrick
@Patrick: OK I understand. I personally used MessageBox/WTSSendMessage way since almost 18 years (Windows NT 3.1 beta). It seems a little primitive, but it work. You can use it also together with the remote debugging. The way with IntelliTrace looks like very interesting, but I personally not yet test it. Lucky debugging!
Oleg