views:

88

answers:

4

I am using Visual Studio 2010, and coding in C#. I have a third-party dll that I am using in my project. When I attempt to use a specific method, at seemingly random occasions, the program simply crashes, with no exception thrown. The session simply ends. Is there any way I can trace what is going on?

+3  A: 

Try to force the debugger to catch even handled exceptions - especially the bad ones like Access Violation and Stack Overflow. You can do this in Debug -> Exceptions. It is possible that the third-party DLL catches all exceptions and then calls exit() or some similar beauty which quits the whole program.

dark_charlie
I set it so that both StackOverflow and AccessViolation exceptions are thrown, but again, nothing is thrown.
sbenderli
Do you have debug symbols available for that dll? What language is that DLL written in? Is it a managed or unmanaged DLL? You can also simply try to check everything in the exceptions window and wait :)
dark_charlie
It is an interop dll. It says that the Primary Interop Assembly is also installed into the Global Assembly Cache (GAC) if you have the .NET framework installed. Would this mean it is managed?
sbenderli
I set all the exceptions to be thrown, but no fireworks :(
sbenderli
@sbenderli It is probably managed. Then the dll probably terminates the application directly, without throwing an exception. I guess you should contact the vendor or find another vendor...
dark_charlie
@dark_charlie I'll look into it..thanks a lot
sbenderli
+2  A: 

Have you checked the Windows Event Log? You can access that in the Admin Tools menu > Event Viewer. Check in the Application and System logs particularly.

DOK
Nothing in the logs :(
sbenderli
+7  A: 

The way the stack for a thread is laid out in Windows goes like this (roughly; this is not an exact description of everything that goes on, just enough to give you the gist. And the way the CLR handles stack pages is somewhat different than how unmanaged code handles it also.)

At the top of the stack there are all the committed pages that you are using. Then there is a "guard page" - if you hit that page then the guard page becomes a new page of stack, and the following page becomes the new guard page. However, the last page of stack is special. If you hit it once, you get a stack overflow exception. If you hit it twice then the process is terminated immediately. By "immediately" I mean "immediately" - no exception, go straight to jail, do not pass go, do not collect $200. The operating system reasons that at this point the process is deeply diseased and possibly it has become actively hostile to the user. The stack has overflowed and the code that is overflowing the stack might be trying to write arbitrarily much garbage into memory. (*)

Since the process is potentially a hazard to itself and others, the operating system takes it down without allowing any more code to run.

My suspicion is that something in your unmanaged code is hitting the final stack page twice. Almost every time I see a process suddenly disappear with no exception or other explanation its because the "don't mess with me" stack page was hit.

(*) Back in the early 1990s I worked on database drivers for a little operating system called NetWare. It did not have these sorts of protections that more modern operating systems now have routinely. I needed to be able to "switch stacks" dynamically while running at kernel protection level; I knew when my driver had accidentally blown the stack because it would eventually write into screen memory and I could then debug the problem by looking at what garbage had been written directly to the screen. Ah, those were the days.

Eric Lippert
A: 

If your third-party dll is managed, using Runtime Flow you can see what happens inside of it before the crash - a stack overflow, a forceful exit or an exception will be clearly identifiable.

Sergey Vlasov