visual studio .net debugging: Hi,

i have problem with debugging. Almost every time when my application
encounters an error "Visual Studio Just-In-Time Debugger" window pops up
with message : "An unhandled win32 exception occured in
<Project_name>.vshost.exe instead of breaking into the line of code that has
the error. Then i can choose between possible debuggers and if i click "yes"
to debug using selected debugger then new Visual Studio 2005 instance opens
to debug <project_name>.vshost.exe with error message "unable to attach to
the crashing process. a debbuger is already attached".

Please help!

[quoted text, click to view]

When you see the message, break into the already attached debugger (Debug | Break All).
What will be on the call stack of the thread that is displaying the message?

Also try the same with the hosting process disabled - will the behavior change?
(Project properties | Debug | "Enable the Visual Studio hosting process")

--
Oleg
[VC++ MVP http://www.debuginfo.com/]

We need to get the full call stack somehow, so that it would include
the .NET runtime functions, to guess what they are doing at the moment.
Try to get the call stack with "Just My Code" disabled
(Tools | Options | Debugging | General | "Enable Just My Code" - uncheck)

You can also try WinDbg and SOS (while the message is still displayed,
attach WinDbg to the same process in non-invasive mode and use SOS
to get call stacks). To attach WinDbg, use "File | Attach to Process" menu,
select the process in the list, and make sure "Noninvasive" checkbox
is checked. The output of the following commands would be interesting:

..symfix c:\symbols
..reload
..loadby sos mscorwks
!threads
kb
!clrstack
!dumpstack

If the default thread displayed by WinDbg is not the one that shows the message,
switch to the right one using "~1 s" command, where 1 should be replaced
with the zero-based index of the thread (e.g. try all threads starting with 0 index
and verify the call stack with !clrstack command, until you find the correct thread).
Then repeat the commands.

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

Oleg

When i break into the already attached debugger this is on the call stack:

[External Code]
[quoted text, click to view]
some_method(int index = 1) Line 325 + 0x9 bytes C#
some_method(object sender = {System.Windows.Forms.TabControl},
System.EventArgs e = {System.EventArgs}) Line 221 + 0x9 bytes C#
[External Code]
Main() Line 21 + 0x1a bytes C#
[External Code]

With the hosting process disabled the behavior is the same.


[quoted text, click to view]

this is what i get with "Just my code disabled" :

--------------------------------------
[Managed to Native Transition]
[quoted text, click to view]
some_method(string text = "50 x 50") Line 346 + 0x9 bytes C#
some_method(object sender = {System.Windows.Forms.TabControl},
System.EventArgs e = {System.EventArgs}) Line 233 + 0x3c bytes C#
System.Windows.Forms.dll!System.Windows.Forms.TabControl.OnSelectedIndexChanged(System.EventArgs
e) + 0x76 bytes
System.Windows.Forms.dll!System.Windows.Forms.TabControl.WmSelChange() +
0xd9 bytes
System.Windows.Forms.dll!System.Windows.Forms.TabControl.WndProc(ref
System.Windows.Forms.Message m = {System.Windows.Forms.Message}) + 0x129
bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref
System.Windows.Forms.Message m) + 0xd bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref
System.Windows.Forms.Message m) + 0xd6 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr
hWnd, int msg = 8270, System.IntPtr wparam, System.IntPtr lparam) + 0x75
bytes
[Native to Managed Transition]
[Managed to Native Transition]
System.Windows.Forms.dll!System.Windows.Forms.Control.SendMessage(int msg,
System.IntPtr wparam, System.IntPtr lparam) + 0x3d bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ReflectMessageInternal(System.IntPtr
hWnd, ref System.Windows.Forms.Message m = {System.Windows.Forms.Message}) +
0x3e bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WmNotify(ref
System.Windows.Forms.Message m = {System.Windows.Forms.Message}) + 0x2e
bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref
System.Windows.Forms.Message m) + 0x6a6 bytes
System.Windows.Forms.dll!System.Windows.Forms.ScrollableControl.WndProc(ref
System.Windows.Forms.Message m) + 0x45 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref
System.Windows.Forms.Message m) + 0xd bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref
System.Windows.Forms.Message m) + 0xd6 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr
hWnd, int msg = 78, System.IntPtr wparam, System.IntPtr lparam) + 0x75 bytes
[Native to Managed Transition]
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref
System.Windows.Forms.Message m = {System.Windows.Forms.Message}) + 0x94
bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.DefWndProc(ref
System.Windows.Forms.Message m) + 0xc bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WmMouseDown(ref
System.Windows.Forms.Message m = {System.Windows.Forms.Message},
System.Windows.Forms.MouseButtons button = Left, int clicks = 1) + 0xf5
bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref
System.Windows.Forms.Message m) + 0x52d bytes
System.Windows.Forms.dll!System.Windows.Forms.TabControl.WndProc(ref
System.Windows.Forms.Message m) + 0x1f2 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref
System.Windows.Forms.Message m) + 0xd bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref
System.Windows.Forms.Message m) + 0xd6 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr
hWnd, int msg = 513, System.IntPtr wparam, System.IntPtr lparam) + 0x75
bytes
[Native to Managed Transition]
[Managed to Native Transition]
System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(int
dwComponentID, int reason = -1, int pvLoopData = 0) + 0x2ea bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int
reason = -1, System.Windows.Forms.ApplicationContext context =
{System.Windows.Forms.ApplicationContext}) + 0x17d bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int
reason, System.Windows.Forms.ApplicationContext context) + 0x53 bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.Run(System.Windows.Forms.Form
mainForm) + 0x2e bytes
Main() Line 21 + 0x1a bytes C#
[Native to Managed Transition]
[Managed to Native Transition]
mscorlib.dll!System.AppDomain.ExecuteAssembly(string assemblyFile,
System.Security.Policy.Evidence assemblySecurity, string[] args) + 0x32
bytes
Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
+ 0x2b bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object
state) + 0x3b bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext
executionContext, System.Threading.ContextCallback callback, object state) +
0x81 bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x40 bytes
-----------------------------------------

I never worked with Windbg so i didn't figure it out how to check that
thread that is displayed by WinDbg is the one that shows the message?

this is what i get when i execute commands that you said (default thread
displayed) :

*** wait with pending attach
Symbol search path is:
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
WARNING: Process 3644 is not attached as a debuggee
The process can be examined but debug events will not be received
..........................................................................
Loading unloaded module list
.....
(e3c.b18): Wake debugger - code 80000007 (first chance)
eax=00000000 ebx=0012f4cc ecx=00185c00 edx=0012f2e0 esi=00000000
edi=7ffd7000
eip=7c90eb94 esp=0012f4a4 ebp=0012f540 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret
0:000> .symfix c:\symbols
0:000> .reload
Reloading current modules
...........................................................................
0:000> .loadby sos mscorwks
0:000> !threads
ThreadCount: 10
UnstartedThread: 0
BackgroundThread: 6
PendingThread: 0
DeadThread: 2
Hosted Runtime: no
PreEmptive GC Alloc Lock
ID OSID ThreadOBJ State GC Context Domain Count
APT Exception
0 1 b18 00185c00 201a228 Enabled 00000000:00000000 00149648 0
MTA
2 2 654 0018f340 b228 Enabled 00000000:00000000 00149648 0
MTA (Finalizer)

OK. In the output of !threads, there is this thread:

[quoted text, click to view]

It mentions an exception, so probably that's the thread we need - its index is 11 (the first column).
Try the following:

~11 s
kb
!clrstack
!dumpstack

(the next time you might get another thread index, so check !threads output again,
find the thread with the exception and pass its index to the '~' command).

Oleg

It looks like by some reason the exception filter installed by .NET runtime
refuses to handle the exception. I can't yet tell why. Some questions:

- Does this problem happen with only this particular application,
or with any other application on this system?
- If the latter, does it happen with simple, wizard-generated application?
- Does it happen with any type of .NET exception? (Try to throw a hard-coded
exception in the application)
- Do breakpoints in the debugger work, and is it possible to single-step through
the application's code in the debugger? (especially through the function that
later raises the exception)

Oleg

And one more question:
What will be reported by the following command in WinDbg:
(again, while the application is still showing the message)

dd mscorwks!g_fForbidEnterEE L1

(you don't have to load SOS this time, so the simplest sequence of commands
could be:

..symfix c:\symbols
..reload
dd mscorwks!g_fForbidEnterEE L1

Oleg

[quoted text, click to view]

Thank you for your effort!

I got it now.

This is what i get :


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

*** wait with pending attach
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:
WARNING: Process 2684 is not attached as a debuggee
The process can be examined but debug events will not be received
..........................................................................
Loading unloaded module list
.....
(a7c.1fc): Wake debugger - code 80000007 (first chance)
eax=00000000 ebx=0012f4cc ecx=00185c00 edx=0012f2e0 esi=00000000
edi=7ffdc000
eip=7c90eb94 esp=0012f4a4 ebp=0012f540 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\ntdll.dll -
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret
0:000> .symfix c:\symbols
0:000> .reload
Reloading current modules
...........................................................................
0:000> .loadby sos mscorwks
0:000> !threads
ThreadCount: 10
UnstartedThread: 0
BackgroundThread: 6
PendingThread: 0
DeadThread: 2
Hosted Runtime: no
PreEmptive GC Alloc Lock
ID OSID ThreadOBJ State GC Context Domain Count
APT Exception
0 1 1fc 00185c00 201a220 Enabled 00000000:00000000 00149648 0
MTA
2 2 578 0018f340 b220 Enabled 00000000:00000000 00149648 0
MTA (Finalizer)
3 3 fa0 001ceba0 220 Enabled 00000000:00000000 00149648 0
Ukn
5 4 964 001d7ae0 220 Enabled 00000000:00000000 00149648 0
Ukn
XXXX 5 0 001d97c8 9820 Enabled 00000000:00000000 00149648 0
Ukn
XXXX 6 0 001e5c08 9820 Enabled 00000000:00000000 00149648 0
MTA
6 7 ec4 001e6ff0 180b220 Enabled 00000000:00000000 00149648 0
MTA (Threadpool Worker)
8 8 f38 001f4d20 b020 Enabled 00000000:00000000 00149648 0
MTA
9 9 dd4 001e66a8 b220 Enabled 00000000:00000000 00149648 0
MTA
11 a 9dc 001fa6e0 7020 Enabled 013444a8:01344ab0 00149648 0
STA System.NullReferenceException (01335664)
0:000> ~11 s
eax=051f0000 ebx=03b8cc20 ecx=00001000 edx=7c90eb94 esi=000004fc
edi=00000000
eip=7c90eb94 esp=03b8cc04 ebp=03b8d344 iopl=0 nv up ei pl nz na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000206
ntdll!KiFastSystemCallRet:
7c90eb94 c3 ret
0:011> kb
ChildEBP RetAddr Args to Child
03b8cc00 7c90e9ab 7c863764 00000002 03b8cd48 ntdll!KiFastSystemCallRet
03b8cc04 7c863764 00000002 03b8cd48 00000001
ntdll!ZwWaitForMultipleObjects+0xc
03b8d344 7c83ab20 03b8d36c 7c839b09 03b8d374
KERNEL32!UnhandledExceptionFilter+0x8e4
03b8d34c 7c839b09 03b8d374 00000000 03b8d374 KERNEL32!BaseThreadStart+0x4d
03b8d374 7c9037bf 03b8d460 03b8ffdc 03b8d47c KERNEL32!_except_handler3+0x61
03b8d398 7c90378b 03b8d460 03b8ffdc 03b8d47c ntdll!ExecuteHandler2+0x26
03b8d448 7c90eafa 00000000 03b8d47c 03b8d460 ntdll!ExecuteHandler+0x24
03b8d448 00cb8e0b 00000000 03b8d47c 03b8d460
ntdll!KiUserExceptionDispatcher+0xe
*** WARNING: Unable to verify checksum for PhotoCabin.exe
03b8d7b8 00cb8d90 00000000 00000000 00000000
PhotoCabin!PhotoCabin.MainForm.SelectPicFormatButton(System.Windows.Forms.Button)+0x5b
[E:\My Documents\Visual Studio
2005\Projects\PhotoCabin\PhotoCabin\MainForm.cs @ 378]
03b8d80c 00cb899a 00000000 00000000 00000000
PhotoCabin!PhotoCabin.MainForm.CreatePicFormatButton(System.String)+0xc0
[E:\My Documents\Visual Studio
2005\Projects\PhotoCabin\PhotoCabin\MainForm.cs @ 346]
03b8d8f0 7b2b8efa 00000000 00000000 00000000
PhotoCabin!PhotoCabin.MainForm.tbcSettings_SelectedIndexChanged(System.Object,
System.EventArgs)+0x45a [E:\My Documents\Visual Studio
2005\Projects\PhotoCabin\PhotoCabin\MainForm.cs @ 233]
*** WARNING: Unable to verify checksum for
C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System.Windows.Forms\9002a3a99680534eab3769a739b8cd14\System.Windows.Forms.ni.dll
012c95a0 7b2ba275 00000000 00000000 00000000
System_Windows_Forms_ni!System.Windows.Forms.TabControl.OnSelectedIndexChanged(System.EventArgs)+0x76
012d78d8 7b2ba609 00000000 00000000 00000000
System_Windows_Forms_ni!System.Windows.Forms.TabControl.WmSelChange()+0xd9
03b8d980 7b07a72d 00000000 00000000 00000000
System_Windows_Forms_ni!System.Windows.Forms.TabControl.WndProc(System.Windows.Forms.Message
ByRef)+0x129
03b8d9b4 7b07a706 00000000 00000000 00000000
System_Windows_Forms_ni!System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message
ByRef)+0xd
03b8d9b4 7b08b845 00000000 00000000 00000000
System_Windows_Forms_ni!System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message
ByRef)+0xd6
03b8d9b4 79e88f63 00000000 00000000 00000000
System_Windows_Forms_ni!System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr,
Int32, IntPtr, IntPtr)+0x75
03b8d9d0 79e88ee4 03b8dadc 00000003 03b8daa0 mscorwks!CallDescrWorker+0x33
03b8da50 79f2905b 03b8dadc 00000003 03b8daa0
mscorwks!CallDescrWorkerWithHandler+0xa3
03b8da70 79f29369 7b684c90 03b8dad0 0000000c
mscorwks!ForwardCallToManagedMethod+0x55
0:011> !clrstack
OS Thread Id: 0x9dc (11)
ESP EIP
03b8d748 00cb8e0b
PhotoCabin.MainForm.SelectPicFormatButton(System.Windows.Forms.Button)
03b8d7c0 00cb8d90 PhotoCabin.MainForm.CreatePicFormatButton(System.String)
03b8d814 00cb899a
PhotoCabin.MainForm.tbcSettings_SelectedIndexChanged(System.Object,
System.EventArgs)
03b8d8fc 7b2b8efa
System.Windows.Forms.TabControl.OnSelectedIndexChanged(System.EventArgs)
03b8d910 7b2ba275 System.Windows.Forms.TabControl.WmSelChange()
03b8d924 7b2ba609
System.Windows.Forms.TabControl.WndProc(System.Windows.Forms.Message ByRef)
03b8d964 7b07a72d
System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message
ByRef)
03b8d968 7b07a706
System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message
ByRef)
03b8d97c 7b08b845
System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr, Int32, IntPtr,
IntPtr)
03b8daf0 79e88f63 [GCFrame: 03b8daf0]
03b8dc90 79e88f63 [UMThkCallFrame: 03b8dc90]
03b8ddfc 79e88f63 [NDirectMethodFrameGeneric: 03b8ddfc]
System.Windows.Forms.UnsafeNativeMethods.SendMessage(System.Runtime.InteropServices.HandleRef,

It looks like i know what is causing this, but also can't tell why.

If i throw a hard-coded exception before InitializeComponent() method
exception filter handles the exception and i get expected exception
description window. But if do that any time after InitializeComponent()
method exception is not caught. My first tought was that it must be some
control that is causing that. So naturaly i first removed
AxShockwaveFlashObjects.AxShockwaveFlash control that i use to play swf
animation and symptoms are gone!

I am not sure if answer to your questions could help to identify why is this
happening but i'll answer the questions anyway. I could add control to
application when application is almost done to avoid this problem in
development time, but i am already not using full screen ability because
when i close application in debug time Visual Studio becomes topmost window
and IntelliSense doesn't show until i restart Visual Studio.

Answers:
- It happens to application that use
AxShockwaveFlashObjects.AxShockwaveFlash control.
- Breakpoints work and it is possible to single-step through code anywhere
in application, right to the line where exception is thrown

The command dd mscorwks!g_fForbidEnterEE L1 returns this :
7a38d5e4 00000000

I'm not sure if anyone told you that before, but you are DEBUGGING
MASTER!!!!!

It works!!!!! .NET runtime exception filter is back in the game!

Thank you very much for your time and effort!!!!

[quoted text, click to view]

That whould be good, but code inside InitializeComponent() is controlled by
designer, so any change will be deleted once designer put his hands on the
code (every time when i open designe view).

But since that code is designer responsibility, that should not be the place
to expect exceptions.

[quoted text, click to view]

It's a good find. My first guess would be that the control installs
its own custom filter for unhandled exceptions, and disables .NET runtime's one
(the latter is responsible for reporting unhandled exceptions to the debugger).

Try the following code around InitializeComponent:

IntPtr SaveFilter = SetUnhandledExceptionFilter(IntPtr.Zero);
InitializeComponent();
SetUnhandledExceptionFilter(SaveFilter);

P/Invoke signature is like this:
[DllImport("kernel32.dll")]
static extern IntPtr SetUnhandledExceptionFilter(IntPtr lpFilter);

With this code, will the debugger start reporting unhandled exceptions
thrown _after_ InitializeComponent has completed?

Oleg

[quoted text, click to view]

Thanks :)

One more thing - try to narrow down the scope of the two calls
to SetUnhandledExceptionFilter (because the first of our two calls
also in fact disables the .NET filter, and the second one restores it).
It's best to make these two calls around the initialization code of
the problematic control, somewhere inside InitializeComponent.

Oleg