Question

For debugging environments, we have a conditional Debugger.Launch statement in the code to allow developers to debug into the startup code of the windows service. We just upgraded to .NET 4.0 today. Since the upgrade, if we exit out of the JIT window (i.e. we chose not to debug), the Windows Service is crashing (process is terminating). It used to simply resume. If we accept to attach, the application does not terminate and works fine.

EDIT

Another strange thing is that the exception that is thrown is no longer a Launch for User exception. It is now an unhandled Microsoft .NET framework exception. I’ve tried to wrap a try catch arround it to see what i get. I can’t catch the exception when i’m debugged in because at that point the exception doesn’t occur. If i try to log the exception to a file, the Service crashes and i get nothing.

Any way to fix this? Any reason for it?

MORE INFO

I just created a blank and new windows form application.

        public Form1()
        {
            try
            {
                MessageBox.Show("hello");
                System.Diagnostics.Debugger.Launch();

            }
            catch
            {
                MessageBox.Show("error");
            }
            AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
            InitializeComponent();
        }

        void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
        {
            MessageBox.Show(e.ToString());
        }

I get the first “hello”. Then i get the JIT window which says an “unhandled Microsoft .NET exception has occured”. If i do not attach, it crashes without a message or anything.

I tried WinDbg and what not. I’m not familiar at all with those tools. Here is what i’m getting. It does not appear very useful at all

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\moueis\TestDebugging_100927_104956.dmp]
User Mini Dump File with Full Memory: Only application data is available

Comment: '
*** C:\Users\moueis\Desktop\procdump.exe  TestDebugging.exe -e -ma
*** Unhandled exception'
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is: 
Windows 7 Version 7600 MP (8 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Debug session time: Mon Sep 27 10:49:56.000 2010 (UTC - 4:00)
System Uptime: 11 days 20:41:04.714
Process Uptime: 0 days 0:00:22.000
.........................................
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for KERNELBASE.dll - 
KERNELBASE!DebugBreak+0x2:
000007fe`fd432442 cc              int     3

This is happening on more than 1 machine (however, they are extreamly similar).

AGAIN MORE INFO

This is apparently pretty easy to reproduce. It has occured on multiple systems in house and I’ve received confirmation from an external party that the problem can be reproduced simply by using the code snippet above in a .NET windows form that uses .NET 4.0

Answer 1

I encountered this same issue and via some Googling found the Microsoft Connect report for it.