vb.net VShost32.exe 停止工作，但我可以继续调试
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/14381842/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
VShost32.exe stopped working, but I can continue debugging
提问by Eric
My application first reads data from a database and then creates an XML document to be uploaded to a SFTP server.
我的应用程序首先从数据库读取数据，然后创建要上传到 SFTP 服务器的 XML 文档。
When I run the application I get an error:
当我运行应用程序时，我收到一个错误：
VShost32.exe stopped working
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?
另外，我怎样才能摆脱它？
回答by Hans Passant
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.
VSHost32.exe 是 Visual Studio 托管进程。它有一个自定义托管的 CLR 版本，使调试更容易。实际进程名是yourapp.vshost.exe，可以在任务管理器中看到它正在运行。
So what the message really means is that yourprogram 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 afterthe hosting process has seen it. Which is pretty remarkable.
您能够在这次崩溃后继续调试是非常不寻常的，并且可能非常不健康。如果您使用的库使用 SetUnhandledExceptionFilter() 安装其自己的未处理异常过滤器并吞下异常，则这在技术上是可行的。但是在托管过程看到它之后这样做。这是非常了不起的。
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.
通过启用非托管调试器获得更好的诊断。项目+属性，调试选项卡，勾选“启用非托管代码调试”选项。然后调试 + 异常，勾选 Win32 异常的抛出复选框。重现崩溃场景，调试器现在应该在抛出异常时停止。查看调用堆栈以获取提示。您将看不到任何可识别的内容，因为可能没有崩溃代码的任何调试信息。但希望包含代码的 DLL 的名称可以让您看到是哪个库对此负责。然后联系图书馆的供应商并询问详细信息。
