5

My application first reads data from a database and then creates an XML document to be uploaded to a SFTP server.

When I run the application I get an error:

VShost32.exe stopped working

When I run the application in debug mode and step through it, I find the point where the error pops up, but I can still continue to step to the next steps (as long as I don't close the pop up). Then, everything that should be done, is done. No problems at all.

So why do I get this error message? It's completely unclear on what is causing it.

Also, How can I get rid of it?

John Koerner
  • 37,428
  • 8
  • 84
  • 134
Eric
  • 695
  • 9
  • 25
  • 1
    The VSHost contains temporary data for debugging among other things, so it crashing will not result in your app stopping working. What line does it crash on? – John Koerner Jan 17 '13 at 15:13

1 Answers1

7

VSHost32.exe is the Visual Studio Hosting process. It has a custom-hosted version of the CLR that makes debugging easier. The actual process name is yourapp.vshost.exe, you can see it running in Task Manager.

So what the message really means is that your program has crashed, but not in way that the debugger can identify. Which is technically possible if the library you use starts its own unmanaged thread and that thread crashed on an unhandled exception. By default, the debugger can only diagnose exceptions that are raised on a thread started by managed code.

That you able to continue debugging after this crash is very unusual and potentially pretty unhealthy. This is technically possible if the library you use installs its own unhandled exception filter with SetUnhandledExceptionFilter() and swallows the exception. But does so after the hosting process has seen it. Which is pretty remarkable.

Get better diagnostics about this by enabling the unmanaged debugger. Project + Properties, Debug tab, tick the "Enable unmanaged code debugging" option. Then Debug + Exceptions, tick the Thrown checkbox for Win32 Exceptions. Repro the crash scenario, the debugger should now stop when the exception is thrown. Look at the call stack for hints. You are not going to be able to see much of anything recognizable since there probably isn't any debug info for the code that crashed. But hopefully the name of the DLL that contains the code lets you see what library is responsible for this. Then contact the vendor of the library and ask for details.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thanks, I did the settings you have. I now get a popup window with this message: "First-chance exception at 0x0f4e29e1 in ESICrie2Monet.exe: 0xC0000005: Access violation reading location 0x072e3b69." If I hit BREAK it wants the pdb file for the library I was already suspecting. – Eric Jan 17 '13 at 19:16
  • 1
    Good, it makes all sense. Access violations are gross exceptions, the library should not be swallowing them. If you can't get help from the vendor then do consider ditching it. – Hans Passant Jan 17 '13 at 19:24
  • I just upgraded the library version from .net 4.0 x86 to .net 4.5 x64 and although I was unable to debug it in VS2012, I was able to run it by executable and that went flawless. – Eric Jan 17 '13 at 19:41
  • 1
    Be aware that "flawless" on the surface, when underneath the library is accessing invalid memory locations and disabling error detection, makes a fragile system. It might work fine in testing, and maybe even in production for a while, but down the road, your luck could run out. At some point, it might read a valid (but meaningless) memory address and merrily proceed with meaningless data, not working at all or exhibiting some obscure failure when your customer most depends on it. Hacks often come back to bite. – Edward Brey Jan 26 '17 at 12:37
  • I don't see the "Enable unmanaged code debugging" option in visual studio 2015 (c# project) - do you know where can I find it? – STF Jul 10 '17 at 06:27