vshost.exe BEX64 crash on window close

Question

I'm running Visual Studio 2012 with the latest updates and the latest ReSharper on Win7 with latest updates. I have a .NET 4.5 x64 C# Topshelf 3.1.122 wrapped project that uses Entity Framework 6.1. Whether the debugger is attached or not, when I exit the running program by closing the window, vshost.exe will stop working and I'll have to force quit it. This seems to have no discernible effect; it is just annoying. The behavior only occurs on my machine, not the other Dev's. The crash does not occur if Debug session is stopped with the red stop button. Any idea what would cause this?

Problem signature: Problem Event Name: BEX64 Application Name: REDACTED.vshost.exe Application Version: 11.0.50727.1
Application Timestamp: 5011d445 Fault Module Name: ntdll.dll Fault Module Version: 6.1.7601.18247 Fault Module Timestamp: 521eaf24
Exception Offset: 0000000000072c4a Exception Code: c000000d
Exception Data: 0000000000000000 OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033 Additional Information 1: 402a Additional Information 2: 402ac0175590edba59c75743ddb69b2f Additional Information 3: e38f Additional Information 4: e38f53f34d74d36ff87488c7f8d2b32e

This is the Topshelf wrapper code for reference:

    private static void Main()
    {
        HostFactory.Run(
            x =>
            {
                x.Service<Foo>(s =>
                {
                    s.ConstructUsing(name => new Foo());
                    s.WhenStarted(svc => svc.Start());
                    s.WhenStopped(svc => svc.Stop());
                    s.WhenShutdown(svc => svc.Stop());
                });
                x.RunAsLocalSystem();
                x.SetDescription(ServiceInfo.Description);
                x.SetDisplayName(ServiceInfo.DisplayName);
                x.SetServiceName(ServiceInfo.ServiceName);
                x.EnableShutdown();
            });
    }

If I put a break point at the end of Main or at the beginning of the svc.Stop method, the debugger will not break when I close the window, vshost.exe will immediately crash. There isn't anyway I can see how I could step through this.

UPDATE: I used WinDbg to attach to the vshost process and finally got the actual exception:

ntdll!DbgBreakPoint:
00000000`76ef0590 cc              int     3
0:022> g
ModLoad: 000007fe`f7fe0000 000007fe`f7fee000   C:\Windows\system32\wbem\wbemprox.dll
ModLoad: 000007fe`f81f0000 000007fe`f826d000   C:\Windows\system32\wbemcomn2.dll
(3c70.22e8): Unknown exception - code c000000d (first chance)
(3c70.22e8): Unknown exception - code c000000d (!!! second chance !!!)
ntdll!RtlIsDosDeviceName_U+0x1922a:
00000000`76f12c4a 4c8b1d87f70b00 mov     r11,qword ptr [ntdll!NlsAnsiCodePage+0x13e (00000000`76fd23d8)] ds:00000000`76fd23d8=0000000000000000

can you show some code.. do you have any `Exit codes` you are passing.. perhaps you have resources that you need to explicitly free.. and or Dispose of.. are you familiar with `((IDisposable)YourObject).Dispose()` keep in mind that using this that the Object must implement `IDisposable` if not then set the obect(s0 reference = to `null` — MethodMan, Oct 17 '14 at 18:42
@DJKRAZE It's possible that a Singleton unmanaged dll resource that is usually released on exit is the culprit, but it does not occur in other environments, only when hosted by vshost.exe, and only on my machine. I'm suspecting my Nvidia driver based on Google results for ntdll.dll BEX64. — Novaterata, Oct 17 '14 at 18:56
you should not always rely on the Garbage collector because it does not always release resources when one may think it should that's why in your code I would not hurt to add some cleanup of your own.. — MethodMan, Oct 17 '14 at 19:00
@DJKRAZE Thanks for the heads up, but I'm fairly confident I'm disposing all my resources properly, as I've already been through multiple passes with Code Analysis and manual review. — Novaterata, Oct 17 '14 at 19:43
It sounds so much like a possible memory leak but I am sure once you take the time to step thru it again which may or may not be a tedious effort something might stick out.. glad I could lend some advice — MethodMan, Oct 17 '14 at 19:46
@DJKRAZE You know, you might be right, some resources are cleaned up when Stop is called, but it never is if the window is just closed. This isn't a problem normally because it's run as a service. — Novaterata, Oct 17 '14 at 21:38
totally understandable I have noticed so many odd things that happen when running code as a stand alone Console.exe app vs having that same code run / compiled into a service.. makes me wonder if at the service level if one should not use the same or almost similar methods / step when Releasing ComObjects for example I will do some researching on how to Release resources in service Apps sort of like `Marshal.ReleaseComObject` this won't work for Service applications that do not use Interop but there has to be something similar — MethodMan, Oct 20 '14 at 15:27
I still think that `IDisposable` would be the one thing to look into in regards to releasing resources.. also here is an article on [Automatic Memory Management](http://msdn.microsoft.com/en-us/library/f144e03t(v=vs.110).aspx) — MethodMan, Oct 20 '14 at 15:29
I have an additional question you are not distributing `vshost.exe` or using it explicitly meaning launching or running your service using that name within the directory where the application resides are you..? if so that's not common practice.. this could be the root of all your issues / problems — MethodMan, Oct 20 '14 at 15:38
@DJKRAZE I'm just debugging with visual studio 2012 which hosts it with vshost.exe. I believe that is the default behavior. By the way the only resource that is cleaned up in Stop is a CancellationToken is cancelled. I'm really doubting its that. — Novaterata, Oct 20 '14 at 15:45
here is a link with ERROR Codes sounds like a `Stack` Issue based on what I have been reading in some other similar post.. [ERROR CODES](http://www.delphifaq.com/faq/f85.shtml) — MethodMan, Oct 20 '14 at 15:53

vshost.exe BEX64 crash on window close

0 Answers0