here is what I'm trying to solve. I have a crash dump from Google Chrome.
I open windbg and say File -> Symbol File Path:
"SRV*c:\code\symbols*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com"
I guess this looks for the debugging symbols from let to right and should finally grab them from google then. I copied that from http://www.chromium.org/developers/how-tos/debugging.
I drag and drop the crash dump into windbg
And then...
Microsoft (R) Windows Debugger Version 6.2.8400.0 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\cburgdorf\Desktop\Chrome-last.dmp]
User Mini Dump File: Only registers, stack and portions of memory are available
Symbol search path is: SRV*c:\code\symbols*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Wed May 16 16:25:24.000 2012 (UTC + 2:00)
System Uptime: not available
Process Uptime: 0 days 0:01:39.000
.........................................
This dump file has a breakpoint exception stored in it.
The stored exception information can be accessed via .ecxr.
eax=00000000 ebx=0038e1f8 ecx=00000001 edx=0012df58 esi=00000002 edi=0038e218
eip=776e013d esp=0038e1a8 ebp=0038e244 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200246
ntdll!NtWaitForMultipleObjects+0x15:
776e013d 83c404 add esp,4
0:000> .excr
^ Syntax error in '.excr'
You see that it says "The stored exception information can be accessed via .ecxr" but once I insert that it tells me that I have a syntax error.
Does anyone know what I'm doing wrong?
You've got a typo, it's .ecxr :) In the meantime, another easy way to get information out of a crash dump without needing too much WinDbg-fu, is:
.symfix; .reload
!analyze -v
And if this is a .NET App (Chromium isn't but just for extra info), add these three lines
.loadby sos clr
!pe
~*e !clrstack
Related
I am making an exe from an existing VB6 project. During Make, VB crashes with the following message
Visual Basic has stopped working
Problem Event Name: APPCRASH
Application Name: vb6.exe
Application Version: 6.0.97.82
Fault Module Name: ntdll.dll
Exception Code: c0000005
I am able to run the project from VB6 without any trouble. The problem occurs when I try to make the exe.
Please could you let me know what could be wrong?
Thanks!
This all needs to be done on the computer with the fault. I cannot load my ntdll.dll as it a different version and the addresses will be different to yours.
Download and install Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/hh852363
Install the Windows SDK but just choose the debugging tools.
Create a folder called Symbols in C:\
This allows WinDbg to get the symbols for your version of ntdll.dll. Start Windbg. File menu - Symbol File Path and enter
srv*C:\symbols*http://msdl.microsoft.com/download/symbols
then
Open ntdll in WinDbg as a crashdump.
It will show the load address.
Type in WinDbg
ln <modloadaddress> + 7c911780
This will give you the nearest symbol to the crash. It probably isn't useful but lets see.
You can also run VB6 under WinDbg (make sure WinDbg is run as admin). When you crash do a stack trace.
Also do an !Analyze when you crash. It is meant for blue screens but will give info on appcrash.
Type in the WinDbg command prompt
!analyze -v
-v stands for Verbose and if the crash was originated by a program, as opposed to hardware or a driver, it will appear in the middle of the listing.
eg
PROCESS_NAME: java.exe
IMAGE_NAME: ntkrnlmp.exe
PROCESS_NAME only appears in the analyze -v output and only if a program originated the call that faulted.
WinDbg Commands
Open as Executable.
windbg -o -g -G c:\windows\system32\cmd.exe /k batfile.bat
You can press F12 to stop it and kb will show the call stack (g continues the program). If there's errors it will also stop and show them.
There is a breakpoint after loading but before any code is run. Press g to continue. Likewise there is a breakpoint after all code has run but before it is unloaded.
Type lm to list loaded modules, x *!* to list the symbols and bp symbolname to set a breakpoint
If programming in VB6 then this environmental variable link=/pdb:none stores the symbols in the dll rather than separate files. Make sure you compile the program with No Optimisations and tick the box for Create Symbolic Debug Info. Both on the Compile tab in the Project's Properties.
Sample output from a nearest symbol search.
Loading Dump File [C:\Windows\System32\ntdll.dll] Symbol search path
is: srvc:\symbolshttp://msdl.microsoft.com/download/symbols
Executable search path is: ModLoad: 4b280000 4b3f9000
C:\Windows\System32\ntdll.dll eax=00000000 ebx=00000000 ecx=00000000
edx=00000000 esi=00000000 edi=00000000 eip=4b280000 esp=00000000
ebp=00000000 iopl=0 nv up di pl nz na pe nc cs=0000 ss=0000
ds=0000 es=0000 fs=0000 gs=0000 efl=00000000
ntdll!__guard_fids_table (ntdll+0x0): 4b280000 4d
dec ebp 0:000> ln 4b280000 + 65534 (4b2e5520)
ntdll!RtlInitializeBitMap+0x14 | (4b2e5540)
ntdll!TpCallbackUnloadDllOnCompletion
Sample stack trace.
You follow what function called what functions. So you read it from the bottom up. It has the first 4 parameters that were passed to the function. You find the debugger starts additional threads so we need to find our program's one.
~
Lists all threads
~<threadid> e <command>
Do a KB on all threads until you find the main one.
0:004> ~0 e kb
ChildEBP RetAddr Args to Child 04bdfc30
75ae325a 04bdfc70 00000000 00000000 USER32!NtUserGetMessage+0xc
04bdfc4c 00895eb6 04bdfc70 00000000 00000000 USER32!GetMessageW+0x2a
04bdfc8c 008a5b41 00890000 00000000 04e2336f notepad!WinMain+0xe6
04bdfd20 74ad3744 7f229000 74ad3720 10fde46e
notepad!WinMainCRTStartup+0x151 04bdfd34 7755a064 7f229000 b0c1107f
00000000 KERNEL32!BaseThreadInitThunk+0x24 04bdfd7c 7755a02f ffffffff
7757d7c9 00000000 ntdll!__RtlUserThreadStart+0x2f 04bdfd8c 00000000
008a59f0 7f229000 00000000 ntdll!_RtlUserThreadStart+0x1b
Assume that 04bdfc70 is an HWnd. Which it is because the documentation says so. But assume it an address of a string. This displays what is there.
ds 775a1300
or to look at the values
db 775a1300
I have been scouring the web trying to find an answer to this question, but it seems to be eluding me. I have consulting the following sources before asking this question.
http://www.csn.ul.ie/~caolan/publink/winresdump/winresdump/doc/pefile.html
http://msdn.microsoft.com/en-us/magazine/cc301805.aspx
I understand the PE format (or at least I think I do). Using the command-line debugger (cdb), I would like to be able to disassemble the address where the RVA is to see what the first call is. For a native application (like Notepad), I would expect to see notepad!WinMainCRTStartup, and for a .NET application, I would expect to see a jmp command to the CLR.
Using Notepad as an example, I executed dumpbin /headers on it, and got a value of 3570 for the entry point. When I execute cdb notepad and perform this command - u [base address in memory]+0x3570 - I do not get the WinMainCRTStartup call.
Am I misinterpreting the PE output from dumpbin? How can I know exactly where to look in memory for the starting function of an application?
Edit (1/7/13): I forgot to mention that I am running this on 64-bit Windows 7. If I try to use cdb in Windows XP Mode (to get results from a 32-bit OS), disassembling the AddressOfEntryPoint that I get from an analysis of the PE file gets me the call to WinMainCRTStartup as I would expect. In other words, the exact address I am told to look at contains what I think it should in a 32-bit OS. Does running the application on a 64-bit machine truly make that much of a difference?
Just to add complexity, if I do a !dh on the ImageBaseAddress in the 64-bit OS in cdb, I get the EXACT AddressOfEntryPoint that I need to use.
Use the Microsoft Symbol Server to obtain symbol debugging information. http://support.microsoft.com/kb/311503/en-us
0:001> !dh -a notepad
....
3689 address of entry point
...
00ac0000 image base
...
0:001> u ac3689
notepad!WinMainCRTStartup:
Edit: add dumpbin output (entry point the same offset, image base may be different because ASLR works when image loads in memory):
Microsoft (R) COFF/PE Dumper Version 11.00.50727.1
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file c:\windows\notepad.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (x86)
4 number of sections
4A5BC60F time date stamp Tue Jul 14 03:41:03 2009
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
102 characteristics
Executable
32 bit word machine
OPTIONAL HEADER VALUES
10B magic # (PE32)
9.00 linker version
A800 size of code
22400 size of initialized data
0 size of uninitialized data
3689 entry point (01003689) _WinMainCRTStartup
Edit 2 add output for x64
dumpbin:
Microsoft (R) COFF/PE Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file c:\windows\notepad.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (x64)
6 number of sections
4A5BC9B3 time date stamp Tue Jul 14 03:56:35 2009
0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
Application can handle large (>2GB) addresses
OPTIONAL HEADER VALUES
20B magic # (PE32+)
9.00 linker version
A800 size of code
25800 size of initialized data
0 size of uninitialized data
3570 entry point (0000000100003570) WinMainCRTStartup
windbg:
0:000> !dh -a notepad
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (X64)
...
1000 base of code
----- new -----
00000000ff0c0000 image base
...
0:000> u ff0c0000+3570
notepad!WinMainCRTStartup:
I'm trying to dump heap information from full dump memory file sitting on Windows Server 2003 SP2 x86. Dump was created for 32-bit mixed (native/clr) application which was running on Windows Server 2003 SP2 x64 machine.
From the following windbg log I understand that loaded ntdll.dll image is incorrect and does not correspond to ntdll.pdb symbols. I have tried to specify the location to ntdll.dll from the target machine but windbg still shows that the module is loaded from the standard location (c:\windows\system32).
What did I do wrong? How to force windbg to load correct version of ntdll?
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
[ ... skipped ... ]
0:042> vertarget
Windows Server 2003 Version 3790 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
kernel32.dll version: 5.2.3790.4480 (srv03_sp2_gdr.090321-1244)
Machine Name:
Debug session time: Wed Mar 16 16:36:10.000 2011 (GMT-5)
System Uptime: 17 days 10:34:26.068
Process Uptime: 1 days 15:19:14.000
Kernel time: 0 days 1:24:01.000
User time: 0 days 22:07:58.000
0:042> .sympath
Symbol search path is: C:\mscordacwks\v2.0.50727.3615;C:\__exe;SRV*C\Symbols*http://referencesource.microsoft.com/symbols;SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols;SRV*C:\Symbols*http://source.msdn.microsoft.com/symbols
0:042> .exepath
Executable image search path is: C:\__exe;C:\__target\Windows\SysWOW64;
0:042> .reload
[ ... skipped ... ]
0:042> .reload /u ntdll.dll
Unloaded ntdll.dll
0:042> .reload /v /f ntdll.dll
AddImage: C:\WINDOWS\system32\ntdll.dll // why is it still c:\windows\system32
DllBase = 7d600000
Size = 000f0000
Checksum = 000c371a
TimeDateStamp = 4cc1831e
0:042> lm
[ ... skipped ... ]
7d600000 7d6f0000 ntdll (pdb symbols) c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb
0:042> !heap
*************************************************************************
*** Your debugger is not using the correct symbols ***
[ ... skipped ... ]
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
0:042> lmi vm ntdll
start end module name
7d600000 7d6f0000 ntdll (pdb symbols) ntdll.dll
Symbol file: c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb
Image path: C:\WINDOWS\system32\ntdll.dll
Image name: ntdll.dll
Timestamp: Fri Oct 22 07:27:10 2010 (4CC1831E)
CheckSum: 000C371A
ImageSize: 000F0000
File version: 5.2.3790.4789 // this is correct and
Product version: 5.2.3790.4789 // does correspond to target computer
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: MicrosoftR WindowsR Operating System
InternalName: ntdll.dll
OriginalFilename: ntdll.dll
ProductVersion: 5.2.3790.4789
FileVersion: 5.2.3790.4789 (srv03_sp2_gdr.101019-0340)
FileDescription: NT Layer DLL
LegalCopyright: c Microsoft Corporation. All rights reserved.
UPDATE:
I moved a little bit further in my issue. I managed to connect to the live process on the customers side and tried to
investigate heap (heap -s) there and basically I got the same result.
(1520.7c4): Wake debugger - code 80000007 (first chance)
eax=00000000 ebx=00327d50 ecx=00000000 edx=00000000 esi=0030b428 edi=002debe4
eip=7d61c876 esp=002df008 ebp=002df06c iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\ntdll.dll -
ntdll!ZwReadFile+0x15:
7d61c876 c22400 ret 24h
0:000> !heap -s
*************************************************************************
*** Your debugger is not using the correct symbols ***
*** [...skipped...] ***
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
0:000> .reload
Reloading current modules
................................................................
....................................
0:000> !heap -s
*************************************************************************
*** Your debugger is not using the correct symbols ***
*** [...skipped...] ***
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
I think I have a problem similar to one mentioned in this article http://support.microsoft.com/kb/959207.
Environment and problem seem to be the same but dll versions are different, so it is not the solution for me.
I think I have to escalate this problem to Microsoft.
Does anybody know where I should go with this question?
This could happen if dump was created with 64 bit tools. There is good information on Tess's blog that explains the reason why bitness of the dump matters.
The solution appears to be easy but not obvious.
I found a wntdll.pdb slightly bigger than mine which contains required symbols and reloaded it with command .reload /f /i ntdll.dll
and I take the previous build of windbg 6.11.0001.404, in the current one 6.12.0002.633 !heap command still does not work in my case.
It looks like the type _HEAP_ENTRY is not included in the pdb of 2003 SP2 ntdll.dll
Microsoft released a hotfix http://support.microsoft.com/kb/959207, but you seem to have a later ntdll version.
A customer is attempting to capture a minidump of a hang. He fires up WindDbg and successfully attaches to the process. WinDbg displays its header:
Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
and the loaded modules are enumerated.
He enters a dump command:
.dump /m c:\problem.dmp
It reports:
Creating c:\problem.dmp - mini user dump
WriteMemoryFromProcess.Read(0x1f1e000, 0x2000) failed, 0x8007012b
Dump creation failed, Win32 error 0n299
"Only part of a ReadProcessMemory or WriteProcessMemory request was completed."
Error 0x299 is:
The requested operation could not be completed due to a file system limitation
Any ideas what this means or how to diagnose?
Have a look at the /mA switch, it was introduced with 6.10.3:
Type net helpmsg 299, error 299 is
Only part of a ReadProcessMemory or WriteProcessMemory request was completed.
In winerror.h this is ERROR_PARTIAL_COPY
Is the process a 64 bit process? http://winprogger.com/?p=26 lists several reasons this error may occur.
I have a nightly build DOS batch script that invokes devenv.exe to build a solution file. Intermittently I observe a devenv.com crash. I get a DW20.exe "share your pain" dialog.
1) If Debug button is pressed, I am not presented with a usual "Choose your debugger" window. Rather, it does nothing.
2) If I launch a Visual Studio and try to attach to devenv.com, it says that the application appears to be deadlocked or waiting for an operation to finish. (I think because it's debugged by DW20.exe)
What would you recommend I do to get a decent call stack?
EDIT
I was successful in getting WinDBG to attach. Executed the k command. Does the following look like something meaningful that can be passed on to the compiler team? Is there a way to look at the current exception?
(e90.fb8): Break instruction exception - code 80000003 (!!! second chance !!!)
eax=0012ccb8 ebx=04ed2750 ecx=0111bdc4 edx=5a57f004 esi=00000000 edi=14ed1000
eip=77e4bef7 esp=0012ccb4 ebp=0012cd08 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\kernel32.dll -
kernel32!RaiseException+0x3c:
77e4bef7 5e pop esi
Missing image name, possible paged-out or corrupt data.
Missing image name, possible paged-out or corrupt data.
Missing image name, possible paged-out or corrupt data.
Missing image name, possible paged-out or corrupt data.
0:000> k
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0012cd08 5a760cf1 kernel32!RaiseException+0x3c
0012cd58 5a766105 cslangsvc!InMemoryCompile+0x4c6c1
0012cd7c 5a767375 cslangsvc!InMemoryCompile+0x51ad5
0012cd84 5a767637 cslangsvc!InMemoryCompile+0x52d45
00000000 00000000 cslangsvc!InMemoryCompile+0x53007
I am trying to get !analyze -v to work.
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
***** OS symbols are WRONG. Please fix symbols to do analysis.
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: ntdll!_PEB ***
*** ***
*************************************************************************
c0000005 Exception in ext.analyze debugger extension.
PC: 014d7875 VA: 00000000 R/W: 0 Parameter: 0001003f
EDIT 2
I found out that there are these wonderful SOS extensions to WinDBG. Apparently I can use them to debug C# Compiler...
0:000> !PrintException
There is no current managed exception on this thread
0:000> !clrstack
OS Thread Id: 0x9fc (0)
ESP EIP
0012ee08 77e4bef7 [ComPlusMethodFrameGeneric: 0012ee08] Microsoft.Build.Tasks.Hosting.ICscHostObject.Compile()
0012ee18 6be671ab Microsoft.Build.Tasks.Csc.CallHostObjectToExecute()
0012ee48 6c0aed17 Microsoft.Build.Utilities.ToolTask.Execute()
0012ee7c 6bcbb348 Microsoft.Build.BuildEngine.TaskEngine.ExecuteTask(ExecutionMode, System.Collections.Hashtable, Microsoft.Build.BuildEngine.BuildPropertyGroup, Boolean ByRef)
0012ef24 6bcadf87 Microsoft.Build.BuildEngine.Target.ExecuteAllTasks(Microsoft.Build.BuildEngine.DependencyAnalysisResult, System.Collections.Hashtable, System.Collections.Hashtable, Microsoft.Build.BuildEngine.ItemBucket, System.Collections.ArrayList, Microsoft.Build.BuildEngine.BuildPropertyGroup)
0012efa0 6bcac7c0 Microsoft.Build.BuildEngine.Target.ExecuteAllTasks()
0012efec 6bcad05b Microsoft.Build.BuildEngine.Target.Build(System.Collections.IDictionary)
0012f070 6bcacfa6 Microsoft.Build.BuildEngine.Target.Build(System.Collections.IDictionary)
0012f0f4 6bcacfa6 Microsoft.Build.BuildEngine.Target.Build(System.Collections.IDictionary)
0012f178 6bcacfa6 Microsoft.Build.BuildEngine.Target.Build(System.Collections.IDictionary)
0012f1fc 6bc9b20d Microsoft.Build.BuildEngine.Project.DoBuild(System.String[], System.Collections.IDictionary, Boolean)
0012f250 6bca2134 Microsoft.Build.BuildEngine.Engine.BuildProject(Microsoft.Build.BuildEngine.Project, System.String[], System.Collections.IDictionary, Microsoft.Build.BuildEngine.BuildSettings, Boolean)
0012f2ac 6bc9af03 Microsoft.Build.BuildEngine.Project.Build(System.String[], System.Collections.IDictionary)
0012f2c0 04711a36 Microsoft.VisualStudio.Build.ComInteropWrapper.ProjectShim.BuildTarget(System.String, System.Collections.IDictionary)
0012f4f4 79f68cde [GCFrame: 0012f4f4]
0012f650 79f68cde [ComMethodFrame: 0012f650]
I am still looking for a way to examine the exception contents. !PrintException did not find any exceptions.
You might try installing Debugging Tools for Windows then use the -iae option (for NTSD/CDB) or the -I option (for WinDBG) to have one of the debuggers from that package be the JIT/AeDebug debugger.
I finally arrived at an exception type and callstack for the faulting compiler. I did this by saving a full dump file (.dump /ma c:\myCSCdump.dmp), then opening the dump file as you would open any other project file in VS2005. Pressing the run button produced the following in the call stack window:
kernel32.dll!_RaiseException#16() + 0x3c bytes
cslangsvc.dll!ALLOCHOST::ThrowOutOfMemoryException() + 0x10 bytes
cslangsvc.dll!PAGEHEAP::AllocPages() + 0xc1fd8 bytes
cslangsvc.dll!SYMTBL::GrowTable() + 0x5b bytes
cslangsvc.dll!BSYMMGR::AddChild() + 0x3b bytes
cslangsvc.dll!BSYMMGR::CreateGlobalSym() + 0x2ba bytes
cslangsvc.dll!BSYMMGR::CreateMethod() + 0xc bytes
cslangsvc.dll!IMPORTER::ImportMethod() + 0x1d9 bytes
cslangsvc.dll!IMPORTER::DefineImportedType() + 0x3b2 bytes
cslangsvc.dll!CLSDREC::prepareAggregate() + 0x8d bytes
cslangsvc.dll!COMPILER::ForceAggStates() + 0x8e bytes
cslangsvc.dll!COMPILER::ForceAggStates() + 0x127 bytes
cslangsvc.dll!COMPILER::EnsureState() + 0x2e bytes
cslangsvc.dll!CLSDREC::CheckForTypeErrors() + 0x23 bytes
cslangsvc.dll!CLSDREC::CheckForTypeErrors() + 0x2ba bytes
cslangsvc.dll!CLSDREC::CheckForTypeErrors() + 0x80 bytes
cslangsvc.dll!CLSDREC::CheckForTypeErrors() + 0x8a bytes
cslangsvc.dll!CLSDREC::CheckForTypeErrors() + 0x8a bytes
cslangsvc.dll!CLSDREC::CheckForTypeErrors() + 0x8a bytes
cslangsvc.dll!COMPILER::CheckForTypeErrors() + 0x100 bytes
cslangsvc.dll!COMPILER::CompileAll() + 0x546 bytes
cslangsvc.dll!COMPILER::Compile() + 0x7c bytes
cslangsvc.dll!CController::RunCompiler() + 0x177 bytes
cslangsvc.dll!CController::Compile() + 0x16 bytes
cslangsvc.dll!CCSharpProjectSite::BuildProjectCore() + 0x5a bytes
cslangsvc.dll!CProjectSite::BuildProject() + 0x11 bytes
csproj.dll!CCSharpBuildCompiler::DoMainBuild() + 0x88 bytes
csproj.dll!CCscMSBuildHostObject::Compile() + 0x4e bytes
mscorwks.dll!_CLRToCOMWorker#8() + 0x171 bytes
This is a bit wordy, so I'll post it as a reply. It's taken from Microsoft Connect site, in response to my issue. Reader might find it relevant:
Date: Thu, 7 May 2009 19:14:52 -0700
Greetings from Microsoft Connect!
This notification was generated for feedback item: Nightly build troubles (bucket 365749762) which you submitted at the Microsoft Connect site.
Thanks for reporting this issue you've encountered with Visual Studio 2005, and thanks for the dumps you've provided!
It looks like the issue is in cslangsvc.dll (the in-process C# Compiler), which is DevEnv is calling into to perform your build.
Our suggestion to work around this issue would
be to try using MSBuild instead to do your nightly builds, as this should be more robust than automating DevEnv /build. Specifically, you'll likely avoid this particular issue as MSBuild will use csc.exe for compilation rather than cslangsvc.dll.
We're unlikely to have a further VS 2005 release to get out a fix to the cslangsvc issue, so I'm resolving this bug Won't Fix, but please reactivate it if you do still see an issue when using MSBuild.
Thanks again for all the information on this issue!
Alex Turner
Program Manager
Visual C# Compiler