I want to allocate a specific 512MB page which is MEM_FREE, and I want
to change that page to MEM_RESERVE and PAGE_NOACCESS.
Hence, with Windbg, I found a page and I called to
NtAllocateVirtualMemory on that page address with PAGE_RESERVED and
PAGE_NOACCESS.
After this call - I didn't notice that the page got PAGE_NOACCESS
flag(with !address command), but I couldn't change a memory address
inside that page - (I got memory access error for eb command).
So the operation succeeded because I couldn't change the memory.
Do you have an idea why I don't see in windbg PAGE_NOACCESS for
that page after change it's permissions?
Next Step, I called to VirtualQuery on that free page, and the
function failed with error 998 (Invalid access to memory location)
Finally I want to identify free pages and reveal their size.
Do you have an idea how can I get this information it VirtualQuery fails?
Thanks in Advance!
MEM_RESERVE reserves a range of addresses in the VAD tree. It doesn't commit pages that can have protection applied to them. Read the description of the PAGE_* constants. The phrase "committed region of pages" is written repeatedly. The Protect parameter of NtAllocateVirtualMemory says it applies to a "committed region of pages". Similarly flProtect of VirtualAllocEx is valid when "the pages are being committed".
Here's a Python script the commits a page of memory that's protected with PAGE_NOACCESS. Then it attempts to read the first byte, which of course raises an access violation exception.
test.py:
from ctypes import *
MEM_COMMIT = 0x1000
PAGE_NOACCESS = 1
VirtualAlloc = WinDLL('kernel32').VirtualAlloc
VirtualAlloc.restype = c_void_p
addr = VirtualAlloc(None, 4096, MEM_COMMIT, PAGE_NOACCESS)
array = (c_char * 4096).from_address(addr)
array[0] # access violation
demo:
(test) C:\>cdb -xi ld python test.py
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: python test.py
Symbol search path is: symsrv*symsrv.dll*C:\Symbols*
http://msdl.microsoft.com/download/symbols
Executable search path is:
(d70.d08): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00000000`77b78700 cc int 3
0:000> g
(d70.d08): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
python34!PyBytes_FromStringAndSize+0x70:
00000000`64bd5cc0 0fb601 movzx eax,byte ptr [rcx]
ds:00000000`00190000=??
0:000> !address 190000
Usage: <unclassified>
Allocation Base: 00000000`00190000
Base Address: 00000000`00190000
End Address: 00000000`00191000
Region Size: 00000000`00001000
Type: 00020000 MEM_PRIVATE
State: 00001000 MEM_COMMIT
Protect: 00000001 PAGE_NOACCESS
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
While using Application Verifier and windbg to debug one of my VSTO addins, I found out that on Word close I get the following stop:
VERIFIER STOP 00000902: pid 0x3F1C: An HKEY was leaked.
00000632 : Value of the leaked HKEY.
0422EA9C : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
1D3F6FE8 : Address of the owner dll name. Run du <address> to read the dll name.
74040000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
What is the best way to find out the cause of this stop?
Following the advice I did dps 0422EA9C
and the following was returned:
0422ea9c 0423f164
0422eaa0 0000e001
0422eaa4 001c0000
0422eaa8 740f3da0 vfbasics!AVrfpRegOpenKeyW+0xb0
0422eaac 74041e54 oledlg!CStringCache::Init+0x47
0422eab0 74041b51 oledlg!DllMain+0x2e
0422eab4 74041869 oledlg!_CRT_INIT+0x26d
0422eab8 7415c66d verifier!AVrfpStandardDllEntryPointRoutine+0x99
0422eabc 741c95fa vrfcore!VfCoreStandardDllEntryPointRoutine+0x12a
0422eac0 740e7904 vfbasics!AVrfpStandardDllEntryPointRoutine+0xa4
0422eac4 77698d04 ntdll!LdrpCallInitRoutine+0x14
0422eac8 7769c23d ntdll!LdrpRunInitializeRoutines+0x26f
0422eacc 7769aeb5 ntdll!LdrpLoadDll+0x453
0422ead0 7769afcc ntdll!LdrLoadDll+0xaa
0422ead4 740e7d2d vfbasics!AVrfpLdrLoadDll+0x5d
0422ead8 75072ca8 KERNELBASE!LoadLibraryExW+0x1f7
0422eadc 74e548f4 kernel32!LoadLibraryW+0x11
0422eae0 741a6871 vstoee!DllGetClassObject+0x4320
0422eae4 741a68a1 vstoee!DllGetClassObject+0x4350
0422eae8 6b5bfca5 mso!Ordinal4378+0x8dc
0422eaec 6ac85248 mso!MsoFLongSave+0xaa353
0422eaf0 6a686ddd mso!Ordinal9769+0x60b
0422eaf4 6a68667a mso!Ordinal1832+0x13b
0422eaf8 6be22bbb wwlib!DllGetClassObject+0x5dbef
0422eafc 6bdc7c2f wwlib!DllGetClassObject+0x2c63
0422eb00 6bdc4a4b wwlib!FMain+0x253
0422eb04 013815c4 winword+0x15c4
0422eb08 01381558 winword+0x1558
0422eb0c 74e5337a kernel32!BaseThreadInitThunk+0xe
0422eb10 776992b2 ntdll!__RtlUserThreadStart+0x70
0422eb14 77699285 ntdll!_RtlUserThreadStart+0x1b
0422eb18 00000000
Then du 1D3F6FE8
returned
1d3f6fe8 "oledlg.dll"
Interestingly, If I run Application Verifier / WinDbg on Word without my addin loaded I still get a stop:
APPLICATION_VERIFIER_LEAK_ALLOCATION (900)
A heap allocation was leaked.
This stop is generated if the owner dll of the allocation was dynamically unloaded while owning resources.
Arguments:
Arg1: 0b7e2fb8, Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
Arg2: 041495f4, Address to the allocation stack trace. Run dps <address> to view the allocation stack.
Arg3: 0c446fe4, Address of the owner dll name. Run du <address> to read the dll name.
Arg4: 70b50000, Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
GetPageUrlData failed, server returned HTTP status 404
URL requested: http://watson.microsoft.com/StageOne/winword_exe/15_0_4737_1003/559b7227/vrfcore_dll/10_0_15063_137/f4688fdb/80000003/00003809.htm?Retriage=1
Is this the same thing but reported differently?
I looked deeper into this as the very helpful comments above pointed me to think this is not an issue with my addin code but rather with the VSTO host application ie. Word.
So I created a simple VSTO addin with a one button ribbon that just opens a taskpane with a label which says “Hello!” (nothing else – no WPF) and I can confirm that even in this scenario I still get the HKEY Leak on shutdown…
For completeness, when no addins are loaded I get a different stop:
=======================================
VERIFIER STOP 0000000000000300: pid 0x4008: Invalid handle exception for current stack trace.
00000000C0000008 : Exception code.
000000000F9DE670 : Exception record. Use .exr to display it.
000000000F9DE180 : Context record. Use .cxr to display it.
0000000000000000 : Not used.
=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.
=======================================
ModLoad: 711a0000 711c5000 C:\windows\SysWOW64\POWRPROF.DLL
=======================================
VERIFIER STOP 00000900: pid 0x4008: A heap allocation was leaked.
0BDCCFB8 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
041D9C54 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
0C36AFE4 : Address of the owner dll name. Run du <address> to read the dll name.
749C0000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
=======================================
!avrf suggests a APPLICATION_VERIFIER_LEAK_ALLOCATION (900) so I don't think this is a problem with anything but Application Verifier.
I'm trying to start Redis on Windows 10. When I run redis-server.exe I get the following message though:
C:\Program Files\Redis>redis-server.exe
[4680] 01 Jun 19:57:30.844 #
The Windows version of Redis allocates a memory mapped heap for sharing with
the forked process used for persistence operations. In order to share this
memory, Windows allocates from the system paging file a portion equal to the
size of the Redis heap. At this time there is insufficient contiguous free
space available in the system paging file for this operation (Windows error
0x5AF). To work around this you may either increase the size of the system
paging file, or decrease the size of the Redis heap with the --maxheap flag.
Sometimes a reboot will defragment the system paging file sufficiently for
this operation to complete successfully.
Please see the documentation included with the binary distributions for more
details on the --maxheap flag.
Redis can not continue. Exiting.
I've tried adding a --maxheap value, but this causes the application to crash and print out a crash dump:
C:\Program Files\Redis>redis-server.exe --maxheap 150
[6728] 01 Jun 19:57:41.063 #
=== REDIS BUG REPORT START: Cut & paste starting from here ===
[6728] 01 Jun 19:57:41.063 # Redis version: 2.8.2400
[6728] 01 Jun 19:57:41.063 # Out Of Memory allocating 16 bytes.
[6728] 01 Jun 19:57:41.094 # --- ABORT
[6728] 01 Jun 19:57:41.094 # --- STACK TRACE
redis-server.exe!LogStackTrace(c:\release\redis\src\win32_interop\win32_stacktrace.cpp:95)(0x00000016, 0x00001C1D, 0x00000000, 0x00000001)
redis-server.exe!AbortHandler(c:\release\redis\src\win32_interop\win32_stacktrace.cpp:207)(0x00000001, 0xA222916F, 0x00000000, 0xDA31C9A7)
redis-server.exe!raise(f:\dd\vctools\crt\crtw32\misc\winsig.c:587)(0x00000001, 0x00000000, 0x00000010, 0x00000018)
redis-server.exe!abort(f:\dd\vctools\crt\crtw32\misc\abort.c:82)(0xFFE97BC0, 0x40141940, 0x00000010, 0x00000000)
redis-server.exe!redisOutOfMemoryHandler(c:\release\redis\src\redis.c:3404)(0x00000000, 0x4013FC28, 0x00001C1D, 0x0014FB80)
redis-server.exe!createSharedObjects(c:\release\redis\src\redis.c:1326)(0x4013BD44, 0x00000000, 0x00000001, 0x00000001)
redis-server.exe!initServer(c:\release\redis\src\redis.c:1733)(0x4013BD44, 0x4013BD44, 0x00000000, 0x4013BD44)
redis-server.exe!redis_main(c:\release\redis\src\redis.c:3504)(0x00490470, 0x00000000, 0x574F3E35, 0x00000000)
redis-server.exe!main(c:\release\redis\src\win32_interop\win32_qfork.cpp:1338)(0x00000000, 0x00000000, 0x00000000, 0x0034F000)
redis-server.exe!__tmainCRTStartup(f:\dd\vctools\crt\crtw32\startup\crt0.c:255)(0x00000000, 0x400344CC, 0x00000000, 0x00000000)
KERNEL32.DLL!BaseThreadInitThunk(f:\dd\vctools\crt\crtw32\startup\crt0.c:255)(0xD9E580E0, 0x00000000, 0x00000000, 0x00000000)
ntdll.dll!RtlUserThreadStart(f:\dd\vctools\crt\crtw32\startup\crt0.c:255)(0x00000000, 0x00000000, 0x00000000, 0x00000000)
ntdll.dll!RtlUserThreadStart(f:\dd\vctools\crt\crtw32\startup\crt0.c:255)(0x00000000, 0x00000000, 0x00000000, 0x00000000)
[6728] 01 Jun 19:57:41.172 #
=== REDIS BUG REPORT END. Make sure to include from START to END. ===
Please report this bug by following the instructions at:
http://github.com/MSOpenTech/redis/wiki/Submitting-an-Issue
Suspect RAM error? Use redis-server --test-memory to verify it.
I've tried running with the rest memory option suggested at the end of the crash dump, but this just gives me the same error as running the executable did without it:
C:\Program Files\Redis>redis-server.exe --test-memory
[756] 01 Jun 19:58:34.376 #
The Windows version of Redis allocates a memory mapped heap for sharing with
the forked process used for persistence operations. In order to share this
memory, Windows allocates from the system paging file a portion equal to the
size of the Redis heap. At this time there is insufficient contiguous free
space available in the system paging file for this operation (Windows error
0x5AF). To work around this you may either increase the size of the system
paging file, or decrease the size of the Redis heap with the --maxheap flag.
Sometimes a reboot will defragment the system paging file sufficiently for
this operation to complete successfully.
Please see the documentation included with the binary distributions for more
details on the --maxheap flag.
Redis can not continue. Exiting.
I have 14Gb of memory, so I'm finding it hard to believe it's a memory issue.
Found the answer after a wee bit of Google-ing: https://gist.github.com/anthavio/38d0ba4c916ab1911a47
Instead of using the --maxheap option (which seems to do nothing), add the value to the config:
maxheap 1000000000
First let me say I am a total WinDbg noob, so this might be an easy question...
I have an application ("MyApp" - name changed to protect the innocent!) that I am trying to debug because it is throwing an exception. This only happens on user machines - I have not been able to reproduce it on my development machine. So I set up DebugDiag on the users machine and captured a Full Dump. Then I loaded the dump in WinDbg and did an analyze -v and a kp to try to figure out what was going on... but neither of these seem to give me the information that I'm looking for - the function (and hopefully the line number) of the line that is causing the problem... I think I have the symbol file loaded by specifying the path to 'MyApp.pdb' in the Symbol File Path:
srv*c:\symcache*http://msdl.microsoft.com/download/symbols;srv*c:\symcache*C:\dev\Customer\MyAppSln\MyApp\Debug
First, here's the output from kp:
0:004> kp
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0502f474 7c347966 MyApp!DllMain+0x3e8a6
0502f4bc 7c3a2448 msvcr71!_nh_malloc(unsigned int size = <Memory access error>, int nhFlag = <Memory access error>)+0x24 [f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c # 117]
0502f57c 7c3416b3 msvcp71!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::_Tidy(bool _Built = <Memory access error>, unsigned int _Newsize = <Memory access error>)+0x45 [f:\vs70builds\3077\vc\crtbld\crt\src\xstring # 1520]
0502f610 7c3a32de msvcr71!_heap_alloc(unsigned int size = <Memory access error>)+0xe0 [f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c # 212]
0502f620 7c3b3f63 msvcp71!wmemcpy(wchar_t * _S1 = 0x04e463b9 "Ҹ???", wchar_t * _S2 = 0xffffffff "--- memory read error at address 0xffffffff ---", unsigned int _N = 0x4e25212)+0x14 [f:\vs70builds\3077\vc\crtbld\crt\src\wchar.h # 843]
0502f640 04e463b9 msvcp71!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::assign(class std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * _Right = 0xffffffff, unsigned int _Roff = 0x4e25212, unsigned int _Count = 2)+0x7c [f:\vs70builds\3077\vc\crtbld\crt\src\xstring # 601]
0502f770 04df1077 MyApp!DllMain+0x65329
0502f824 04e01b35 MyApp!DllMain+0xffe7
0502ff08 04dfe034 MyApp!DllMain+0x20aa5
0502ff48 04dfde4f MyApp!DllMain+0x1cfa4
0502ff88 7648d0e9 MyApp!DllMain+0x1cdbf
0502ffc4 773499f9 kernel32!BaseThreadInitThunk+0xe
0502ffd4 7738198e ntdll!RtlQueryInformationAcl+0x8b
0502ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
the line I'm specifically trying to decode is the 'MyApp!DllMain+0x65329' as this is the last line that seems to be executing, and the error is occurring within the malloc call, which is apparently where the exception is being thrown from. What am I doing wrong that makes it only display the module and offset instead of source file and line number?
I'm also not sure why the line above the malloc call is back in MyApp again - maybe someone can explain that too.
Just in case, here's the output from 'analyze -v':
0:004> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
*** WARNING: Unable to verify checksum for MyApp.exe
*** ERROR: Module load completed but symbols could not be loaded for MyApp.exe
*** WARNING: Unable to verify checksum for ThirdPartyDll.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ThirdPartyDll.dll -
*** WARNING: Unable to verify checksum for mdnsNSP.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for mdnsNSP.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for SLC.dll -
FAULTING_IP:
MyApp!DllMain+3e8a6
04e1f936 8b16 mov edx,dword ptr [esi]
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 04e1f936 (MyApp!DllMain+0x0003e8a6)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000000
Attempt to read from address 00000000
PROCESS_NAME: MyApp.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
EXCEPTION_PARAMETER1: 00000000
EXCEPTION_PARAMETER2: 00000000
READ_ADDRESS: 00000000
FOLLOWUP_IP:
msvcr71!_heap_alloc+e0 [f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c # 212]
7c3416b3 e88e0c0000 call msvcr71!__SEH_epilog (7c342346)
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
LAST_CONTROL_TRANSFER: from 00000000 to 773bbb33
FAULTING_THREAD: ffffffff
BUGCHECK_STR: APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_NULL_POINTER_READ_SHUTDOWN
PRIMARY_PROBLEM_CLASS: ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_SHUTDOWN
DEFAULT_BUCKET_ID: ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_SHUTDOWN
STACK_TEXT:
773bbb33 ntdll!RtlpAllocateHeap+0x7ad
773a6e0c ntdll!RtlAllocateHeap+0x1e3
7c3416b3 msvcr71!_heap_alloc+0xe0
FAULTING_SOURCE_CODE:
No source found for 'f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c'
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: msvcr71!_heap_alloc+e0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: msvcr71
IMAGE_NAME: msvcr71.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 3e561eac
STACK_COMMAND: dds 7740c078 ; kb
FAILURE_BUCKET_ID: ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_SHUTDOWN_c0000005_msvcr71.dll!_heap_alloc
BUCKET_ID: APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_NULL_POINTER_READ_SHUTDOWN_msvcr71!_heap_alloc+e0
If you believe the PDB should be in your symbol path, you should run something like this:
!sym noisy
.reload MyApp.dll
kp
!sym noisy causes the debugger to give out more detailed information on why it couldn't load symbols - no MyApp.pdb found, found but does not match, etc. This will help you find out why it is not loading symbols. !sym noisy again turns off the verbose symbol output.
When you set the path for symbols, did you reload them?
.reload
I'm not sure your adding
srv*c:\symcache*C:\dev\Customer\MyAppSln\MyApp\Debug
to the symbol path has the desired effect.
I usually list all local paths in the .sympath first, and as the last step, I do .symfix+ to configure the public symbols using the microsoft symbol server:
.sympath C:\dev\Customer\MyAppSln\MyApp\Debug
.symfix+ c:\symcache
the rationale behind listing local paths first being that the debugger would not have to check the remote server for pdbs (that are not there anyways) as opposed to simply retrieving them locally.
Anyways, your problem is that the symbols for MyApp are not loaded therefore stack walking does not quite work.
Debugger walks the stack backwards, starting from the top, that's why you're seeing MyApp - this is where the access violation occurred.
Now, since debugger does not have the symbols at this point, it can only guess what invocation chain has led to the function on top.
And it guesses wrong by following a misleading path.
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