program has exited with code -1073610751 (0xc0020001)

Question

I'm getting a strange error on a SharpDX program I made.

The program contains one form MainForm, which inherits from SharpDX.Windows.RenderForm (I'm doing Direct3D 9). I have some logic that kills the program by calling MainForm.Close(), and it works perfectly.

However, when I close the form with the X button, or by double clicking the top left corner of the screen, the program ends with code -1073610751 (0xc0020001).

This is a relatively minor annoyance, because it only happens when the program is finishing, so it doesn't really matter if it exits with an error, because it is actually finishing.

However, this error does not happen when I set a breakpoint at the last line of my Main(). If I do so, and then close the window as I explained, the breakpoint gets hit, and resuming ends the program with code 0.

Apart from SharpDX and one pure C DLL I am calling to one-shot process some data, I am not doing mixed code, or any other weird stuff.

I've looked around, but this code appears to be related to string bindings? other people seem to have this problem when doing weird mixed C++/CLI stuff, but I'm not doing anything like that.

Any ideas? at least on how to get more concise information on this error code?

Bowerman

Check this link... blogs.msdn.com/b/cbrumme/archive/2003/04/15/51318.aspx - it seems likely from your description that some message handling (or other callbacks from COM to your program) is set up which calls back to your - or SharpDX's - managed methods and isn't cleaned up (in time). If those callbacks then occur after the managed runtime shuts down, you'd get that error. If that theory holds, putting a breakpoint on the last line appears to allow time for the clean up. – Thermodynamic

Perhaps you should debug the code also showing some code would really help if this is a 3rd party .DLL perhaps you need to Dispose of the objects created manually. What have you tried thus far..? – Scrofula

Could it be this? connect.microsoft.com/VisualStudio/feedback/details/336844/… – Aerophobia

@MatthewWatson: I don't think so, because as I said, I'm not using mixed assemblies. Unless SharpDX is doing mixed stuff, but that's very unlikely. – Bowerman

@JimmiTh: That's much more likely than the string binding problem, which I honestly think is a coincidence that they share the same error code. Unfortunately, the message loop is most likely rewritten by SharpDX (I'm not doing custon message processing myself), which would indicate a problem with SharpDX itself... I'll build SharpDX from source later on and post any results in here. – Bowerman

@PandaPajama But if you're using DirectX (via SharpDX), then you must be indirectly using unmanaged code. For example, see: code.google.com/p/sharpdx/issues/detail?id=360 – Aerophobia

@MatthewWatson: As far as I understand, mixed assemblies and interop are two related, but different things... I use interop every day, but so far I have not made my first mixed assembly, and I don't think SharpDX works as a mixed assembly. It calls into DirectX via interop though... – Bowerman

@PandaPajama I think the SharpDX library itself is a mixed assembly. – Aerophobia

@MatthewWatson: I'm just speculating, but it makes no sense to me to make SharpDX as a mixed assembly, as DirectX are a bunch of COM functions, easily callable from C, or C# via vanilla interop. A mixed assembly contains managed and unmanaged code, and as I understand SharpDX's description, it is fully managed code. – Bowerman

It may be a problem in SharpDX itself - or it may be SharpDX attempting (or failing) to clean up something you didn't clean up yourself at the last moment - e.g., like @DJKRAZE says, something you need to Dispose of, or an event handler you need to detach. I'm quite sure the error code is the same one in all cases (in this case) - both the string binding error, and the one I linked involve calls from COM (or unmanaged code) to managed code after the runtime has started shutting down. SharpDX is, indeed, purely managed code, but calling (and being called by) COM. – Thermodynamic

@PandaPajama Ah ok, fair enough! – Aerophobia

It is a hard issue. I suggest using a high-level IDE like Visual Studio 20x, where you can debug step by step each line. – Protecting

Answer 1

It is a very low-level RPC error. Which is likely to be used in your program, it is the underlying protocol on top of which COM runs. There are plenty of candidates, SharpDX itself uses the COM interop layer to make DirectX calls. And DirectX itself is very likely to make such kind of calls to your video driver.

It is also the kind of error code you'd expect to get triggered if there's a shutdown-order problem. Like using a COM interface after it was already released. Shutting down a program cleanly can be a difficult problem to solve, especially when there are lots of threads. There are in any DirectX app. It is also very easy to ignore such a problem, even if it is known and recorded in somebody's bug database. Because, as you noted, the program otherwise shuts down okay without any nasty exceptions. RPC already prevented it from blowing up, you are seeing the error code it generated.

There's very little you can do yourself about this problem, this is code you did not write and you'll never find the programmer who did. If you see a first-chance exception notification in the Output window then you could enable the unmanaged debugger, use Debug + Exceptions and tick the Thrown checkbox for Win32 exception, enable the Microsoft Symbol server and you'll get a stack trace when the exception is thrown. Beware this will be in the bowels of native code with no source to look at. But it could pin-point the DLL that's causing the problem. Still nothing you can do to fix that DLL. I'd recommend a video driver update, the most common source of trouble. That's about as far as you can take it.

Salon

Great answer. Unfortunately, I can see no first-chance exceptions thrown logged in the output window. I'll try with WinDBG as well. – Bowerman