.NET Questions and Solutions

Symptoms
When you run a Transact-SQL script that uses the SET SHOWPLAN_XML ON option in the debugging mode on an instance ofMicrosoft SQL Server 2008, aNullReferenceException error for T-SQL Debugger occurs.
Resolution
This issue occurs when a call to SQL Server Management Objects (SMO) is made from a connection context in which you use the SET SHOWPLAN_XML ON option together with T-SQL Debugger. T-SQL Debugger uses the Server object in SMO to retrieve the version of the instance ofSQL Server that is connected. T-SQL Debugger uses this information to impose the version restriction. This is a known issue associated with T-SQL Debugger.

Symptoms
When you use the Just-In-Time (JIT) debugger, you may experience the following symptoms: You receive the following error message:

“Just -In-Time Debugging Handler and CLR Remote Host: An exception ‘unhandled win32 exception’ has occurred in process ‘processID’. However, Visual Studio 7 just-in-time debugging has failed. Would you like to try debugging with the previously registered debugger (msdev path/msdev.exe)?”You receive an error message and the JIT Debugger does not start.
Resolution
This problem is because the absolute path of the shell resides in the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\shell with a value c:\windows\explorer.exe or c:\winnt\explorer.exe.

Symptoms
Win32 processes can install an unhandled exception filter function to catchexceptions that are not handled in a __try/__except block on a process-widebasis. When debugging such a process, you find that the unhandled exceptionfilter is never executed, even when you put a breakpoint inside it.However, when the process is not being debugged, its unhandled exceptionfilter is called as expected.
Resolution
When called from a process being debugged, the UnhandledExceptionFilter()Win32 API function does not call the application-installed unhandledexception filter.
Note The UnhandledExceptionFilter() API determines whether the process is being debugged. If the process is being debugged, the UnhandledExceptionFilter API passes the exception to the debugger. Then, the UnhandledExceptionFilter API calls the unhandled exception filter for the process.

Symptoms
When you use structured exception handling in a Microsoft Windows Forms application, the exception may not propagate correctly to the calling function. This behavior may occur if you run your Windows Forms application without using the debugger. When this behavior occurs, you may receive the following error message:

An unhandled exception has occurred in your application. If you click continue, the application will ignore this error and attempt to continue. If you click Quit the application will shut down immediately.
My Exception However, if you run your Windows Forms application with the debugger, you may not receive this error message.
Resolution
When you run your Windows Forms application without using the debugger, you use the NativeWindow.CallBack method to catch the exception and to prevent the program from unexpectedly quitting (crashing). In the NativeWindow.CallBack method, you populate the exception message by using a standard exception dialog box.
However, if you run your Windows Forms application with the debugger, you do not catch the exception because you use the NativeWindow.DebuggableCallBack method. When you use the NativeWindow.DebuggableCallBack method, the just-in-time (JIT) debugger stops the application from running.