Geeks With Blogs
Running with Code Like scissors, only more dangerous

On occasion when I start Visual Studio 2005, I encounter a random crash just after the IDE loads.  It doesn't say why, and sending the error report to Microsoft doesn't yield any results.  Oh, and this only happens on my notebook.

After four crashes in a row this afternoon, I got irritated and loaded up WinDbg to see what the problem was.

I got the following:

ModLoad: 71830000 718ad000   C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.762_none_10b2f55f9bffb8f8\msvcm80.dll
(13e4.bc8): CLR exception - code e0434f4d (first chance)
ModLoad: 07900000 07903000   C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\1033\Microsoft.VisualStudio.WebUI.dll
ModLoad: 6f5c0000 6f5c8000   C:\Program Files\Microsoft Visual Studio 8\Visual Studio Tools for Office\vspkgs\1033\VSTOExcelClientPkgUI.dll
ModLoad: 6f570000 6f577000   C:\Program Files\Microsoft Visual Studio 8\Visual Studio Tools for Office\vspkgs\1033\VSTOWordClientPkgUI.dll
(13e4.bc8): CLR exception - code e0434f4d (first chance)
(13e4.bc8): CLR exception - code e0434f4d (first chance)
(13e4.bc8): CLR exception - code e0434f4d (first chance)
(13e4.bc8): CLR exception - code e0434f4d (first chance)
(13e4.bc8): CLR exception - code e0434f4d (first chance)
(13e4.bc8): CLR exception - code e0434f4d (first chance)
(13e4.bc8): CLR exception - code e0434f4d (first chance)
(13e4.bc8): CLR exception - code e0434f4d (first chance)
(13e4.bc8): CLR exception - code e0434f4d (first chance)
(13e4.bc8): CLR exception - code e0434f4d (first chance)
(13e4.bc8): CLR exception - code e0434f4d (first chance)
(13e4.bc8): CLR exception - code e0434f4d (first chance)
(13e4.bc8): Stack overflow - code c00000fd (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0003301c ebx=00000000 ecx=40000000 edx=00000000 esi=0003301c edi=000330fc
eip=770a34eb esp=00033000 ebp=0003304c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
kernel32!SizeofResource+0xcf:
770a34eb 50              push    eax

So it looks like it might be a problem with the Visual Studio Tools for Office - specifically the Word assembly.  Further investigation demonstrates exactly why I'm getting a stack overflow:

0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

FAULTING_IP:
USER32!GetMessageW+6e
773c1a10 648025ca0f0000fe and     byte ptr fs:[0FCAh],0FEh

EXCEPTION_RECORD:  ffffffff -- (.exr ffffffffffffffff)
ExceptionAddress: 770a34eb (kernel32!SizeofResource+0x000000cf)
   ExceptionCode: c00000fd (Stack overflow)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000001
   Parameter[1]: 00032ffc

FAULTING_THREAD:  00000bc8

BUGCHECK_STR:  c00000fd

PROCESS_NAME:  devenv.exe

MODULE_NAME: msenv

FAULTING_MODULE: 77440000 ntdll

DEBUG_FLR_IMAGE_TIMESTAMP:  45dcb74f

ERROR_CODE: (NTSTATUS) 0xc00000fd - A new guard page for the stack cannot be created.

DEFAULT_BUCKET_ID:  WRONG_SYMBOLS

RECURRING_STACK: From frames 0x4 to 0x9

MANAGED_STACK: !dumpstack -EE
OS Thread Id: 0xbc8 (0)
Current frame:
ChildEBP RetAddr  Caller,Callee
00125fa8 7b083587 (MethodDesc 0x7b5bed40 +0x13 System.Windows.Forms.ContainerControl.WndProc(System.Windows.Forms.Message ByRef))

LAST_CONTROL_TRANSFER:  from 770a3a86 to 770a34eb

STACK_TEXT: 
WARNING: Stack unwind information not available. Following frames may be wrong.
0003304c 770a3a86 00000000 00000001 500a99fc kernel32!SizeofResource+0xcf
00033060 773b33f7 500a99fc 0000000c 00033080 kernel32!GlobalFindAtomW+0x11
00033070 500c2953 0001113c 500a99fc 000330ac USER32!SetActiveWindow+0x114
00033080 773c1a10 0001113c 0000000c 00000000 msenv!MsoMakeCustomItem+0x5750d
000330ac 773c1ae8 500c2942 0001113c 0000000c USER32!GetMessageW+0x6e
00033124 773c2d6e 00000000 500c2942 0001113c USER32!GetMessageW+0x146
00033154 773c2d14 500c2942 0001113c 0000000c USER32!CallWindowProcW+0x75
00033174 500c292d 500c2942 0001113c 0000000c USER32!CallWindowProcW+0x1b
-- trimmed --
00033b5c 773c1ae8 500c2942 0001113c 0000000c USER32!GetMessageW+0x6e
00033bd4 773c2d6e 00000000 500c2942 0001113c USER32!GetMessageW+0x146
00033c04 773c2d14 500c2942 0001113c 0000000c USER32!CallWindowProcW+0x75
00033c24 500c292d 500c2942 0001113c 0000000c USER32!CallWindowProcW+0x1b
00033c44 500c2970 0001113c 00000000 0012ae82 msenv!MsoMakeCustomItem+0x574e7
00033c60 773c1a10 0001113c 0000000c 00000000 msenv!MsoMakeCustomItem+0x5752a
00033c8c 773c1ae8 500c2942 0001113c 0000000c USER32!GetMessageW+0x6e
00033d04 773c2d6e 00000000 500c2942 0001113c USER32!GetMessageW+0x146
00033d34 773c2d14 500c2942 0001113c 0000000c USER32!CallWindowProcW+0x75
00033d54 500c292d 500c2942 0001113c 0000000c USER32!CallWindowProcW+0x1b
00033d74 500c2970 0001113c 00000000 0012ae82 msenv!MsoMakeCustomItem+0x574e7
00033d90 773c1a10 0001113c 0000000c 00000000 msenv!MsoMakeCustomItem+0x5752a
00033dbc 773c1ae8 500c2942 0001113c 0000000c USER32!GetMessageW+0x6e
00033e34 773c2d6e 00000000 500c2942 0001113c USER32!GetMessageW+0x146
00033e64 773c2d14 500c2942 0001113c 0000000c USER32!CallWindowProcW+0x75
00033e84 500c292d 500c2942 0001113c 0000000c USER32!CallWindowProcW+0x1b
00033ea4 500c2970 0001113c 00000000 0012ae82 msenv!MsoMakeCustomItem+0x574e7

FOLLOWUP_IP:
msenv!MsoMakeCustomItem+574e7
500c292d 8bf8            mov     edi,eax

SYMBOL_STACK_INDEX:  8

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  msenv.dll

SYMBOL_NAME:  msenv!MsoMakeCustomItem+574e7

STACK_COMMAND:  ~0s ; kb

BUCKET_ID:  WRONG_SYMBOLS

Followup: MachineOwner
---------

(Note: I cut out some of the fluff about using wrong symbols).

I see the stack goes up and up and up - calling GetWindowMessage. GetWindowMessage, CallWindowProc, CallWindowProc, MsoMakeCustomItem, and then all over again.  Calling !dumpstack in WinDbg makes the problem even more apparent: the stack frame is 0x3304c to 0x12ffac - almost an entire megabyte of memory was used repeatedly calling this series of functions.

This problem is fairly new, and I would guess it has something to do with KB936514 (Security Update for Office System 2007), KB936509 (Security Update for Office Excel 2007), KB936646 (Security Update for Office Publisher 2007), or KB937608 (Update for Office Outlook 2007), which were installed among other updates on July 15th for me.

I guess all I can do at this juncture is remove the Visual Studio Tools for Office and pray that they don't kill the rest of my Office setup.  As an alternative to the default Visual Studio Tools for Office System 2003 that comes with Visual Studio 2005, you can get the Microsoft Visual Studio Tools for Office System 2007 here.

UPDATE!

Renaming these two files:

ModLoad: 6f5c0000 6f5c8000   C:\Program Files\Microsoft Visual Studio 8\Visual Studio Tools for Office\vspkgs\1033\VSTOExcelClientPkgUI.dll
ModLoad: 6f570000 6f577000   C:\Program Files\Microsoft Visual Studio 8\Visual Studio Tools for Office\vspkgs\1033\VSTOWordClientPkgUI.dll

to VSTOExcelClientPkgUi.dll.donotload and VSTOWordClientPkgUI.dll.donotload, I was able to launch Visual Studio without any errors.  Apparently, the new Office 2007 updates caused the problem.  I'll be submitting this bug to Microsoft.

Posted on Tuesday, July 24, 2007 1:32 PM | Back to top


Comments on this post: Weird VS2005 Crash Bug

# re: Weird VS2005 Crash Bug
Requesting Gravatar...
You might try using editbin or a hex editor to fudge the default stack value in devenv, -or- set a breakpoint to alter the stack size argument to CreateThread to see if either of those help.
Left by Skywing on Aug 06, 2007 10:59 AM

Your comment:
 (will show your gravatar)


Copyright © Robert Paveza | Powered by: GeeksWithBlogs.net