The Intel Power Gadget tool will not run on my system, and I'm trying to figure out why. It's a Core i7-720QM running Window 8.1 x64. AIDA64 reads the CPU temperatures just fine, but I can't even launch the Intel Power Gadget. No windows open and nothing happens. It works fine on a different computer.
I tried attaching windbg, but it's not obvious what's causing the executable to fail. I haven't been able to find a windbg tutorial which shows how to troubleshoot executables which won't start.
In the following output, I set a breakpoint and dumped the stack as recommended by user blabb. Any ideas?
0:000> .symfix
0:000> .restart
CommandLine: "C:\Program Files\Intel\Power Gadget 3.0\IntelPowerGadget.exe"
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred srv*
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is: srv*
ModLoad: 00007ff6`800f0000 00007ff6`80178000 IntelPowerGadget.exe
ModLoad: 00007ff9`82ab0000 00007ff9`82c5c000 ntdll.dll
ModLoad: 00007ff9`80480000 00007ff9`805be000 C:\Windows\system32\KERNEL32.DLL
ModLoad: 00007ff9`7fcd0000 00007ff9`7fde5000 C:\Windows\system32\KERNELBASE.dll
ModLoad: 00000000`550e0000 00000000`55643000 C:\Windows\SYSTEM32\mfc100u.dll
ModLoad: 00000000`55920000 00000000`559f2000 C:\Windows\SYSTEM32\MSVCR100.dll
ModLoad: 00007ff9`80820000 00007ff9`80997000 C:\Windows\system32\USER32.dll
ModLoad: 00007ff9`82450000 00007ff9`825a1000 C:\Windows\system32\GDI32.dll
ModLoad: 00007ff9`80ce0000 00007ff9`821f9000 C:\Windows\system32\SHELL32.dll
ModLoad: 00007ff9`805c0000 00007ff9`80754000 C:\Windows\system32\ole32.dll
ModLoad: 00007ff9`7b660000 00007ff9`7b810000 C:\Windows\WinSxS\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.9600.17415_none_932b3b5547500489\gdiplus.dll
ModLoad: 00000000`55880000 00000000`55918000 C:\Windows\SYSTEM32\MSVCP100.dll
ModLoad: 00007ff9`823f0000 00007ff9`82444000 C:\Windows\system32\SHLWAPI.dll
ModLoad: 00007ff9`7d8c0000 00007ff9`7db3b000 C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.9600.17415_none_6240486fecbd8abb\COMCTL32.dll
ModLoad: 00007ff9`7cca0000 00007ff9`7cca7000 C:\Windows\SYSTEM32\MSIMG32.dll
ModLoad: 00007ff9`803d0000 00007ff9`8047a000 C:\Windows\system32\msvcrt.dll
ModLoad: 00007ff9`82700000 00007ff9`82911000 C:\Windows\SYSTEM32\combase.dll
ModLoad: 00007ff9`825b0000 00007ff9`826f1000 C:\Windows\system32\RPCRT4.dll
ModLoad: 00007ff9`807c0000 00007ff9`80819000 C:\Windows\SYSTEM32\sechost.dll
(1a58.1a54): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00007ff9`82b71cd0 cc int 3
0:000> bp ntdll!ntTerminateProcess
0:000> bl
0 e 00007ff9`82b41090 0001 (0001) 0:**** ntdll!NtTerminateProcess
0:000> g
ModLoad: 00007ff9`80770000 00007ff9`807a6000 C:\Windows\system32\IMM32.DLL
ModLoad: 00007ff9`80270000 00007ff9`803c3000 C:\Windows\system32\MSCTF.dll
ModLoad: 00007ff9`7e870000 00007ff9`7e999000 C:\Windows\SYSTEM32\UxTheme.dll
ModLoad: 00007ff9`7df70000 00007ff9`7df91000 C:\Windows\system32\dwmapi.dll
ModLoad: 00000000`550d0000 00000000`550dd000 C:\Windows\SYSTEM32\MFC100ENU.DLL
ModLoad: 00007ff9`82a00000 00007ff9`82aaa000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 00007ff9`743b0000 00007ff9`743c1000 C:\Program Files\Intel\Power Gadget 3.0\EnergyLib64.dll
ModLoad: 00007ff9`7f230000 00007ff9`7f276000 C:\Windows\SYSTEM32\POWRPROF.dll
Breakpoint 0 hit
ntdll!NtTerminateProcess:
00007ff9`82b41090 4c8bd1 mov r10,rcx
0:000> kb
RetAddr : Args to Child : Call Site
00007ff9`82b1f400 : 00007e42`e1a67e08 00000000`013f1680 00000000`00000000 00000000`00fafc80 : ntdll!NtTerminateProcess
00007ff9`8048516a : 00000000`00000000 00000000`013f1680 00000000`013f1680 00007ff6`80105bb0 : ntdll!RtlExitUserProcess+0x60
00000000`55940ccd : 00000000`013f1678 00007ff6`863f6e0b 00000000`01181f9e 00000000`00000000 : KERNEL32!ExitProcessImplementation+0xa
*** ERROR: Module load completed but symbols could not be loaded for IntelPowerGadget.exe
00007ff6`800f9e78 : 00000000`00000001 00000000`00000000 00000000`00000000 00000000`00000000 : MSVCR100!doexit+0x1c1
00007ff9`804813d2 : 00007ff6`800f9fc4 00007ff6`7f50b000 00000000`00000000 00000000`00000000 : IntelPowerGadget+0x9e78
00007ff9`82b1eb64 : 00007ff9`804813b0 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x22
00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x34
0:000> g
Breakpoint 0 hit
ntdll!NtTerminateProcess:
00007ff9`82b41090 4c8bd1 mov r10,rcx
0:000> g
ntdll!NtTerminateProcess+0xa:
00007ff9`82b4109a c3 ret
the output in your query is not useful you are simply running the application and windbg is showing all the modules it loaded which doesnt yield any information to the problem in hand you may need to set atleast one breakpoint let windbg break and dump the stack to analyze the path of execution
.restart
when windbg breaks set a bp prior to issuing g when the breakpoint is hit dump the stack backtrace with kb
bp ntdll!ntTerminateProcess
bl
g
kb
edit your post to paste the new output
the function that lead to termination appears to be at 00007ff6`800f9e78
you may need to analyze this function
ub (unassemble backward ) ub 00007ff6`800f9e78 enabling loadersnap !gflag + sls and scanning the debug spew for clues could lead to failures due to dependency should show the call if this call appears to be a terminal call you may need to trace back to determine the branch which leads to this call and analyse why this branch was taken
00007ff6`800f9e78 : 00000000`00000001 00000000`00000000 00000000`00000000 00000000`00000000 : MSVCR100!doexit+0x1c1
00007ff9`804813d2 : 00007ff6`800f9fc4 00007ff6`7f50b000 00000000`00000000 00000000`00000000 : IntelPowerGadget+0x9e78
edit
i took a look at the offending exe it seems there is an integer division by zero exception in EnergyLib64.dll->Initialization Routine called by initterm (LdrpRunInitializeRoutine) when it checks for some processor specific functionality using cpuid the result of cpuid after some calculations is shifted right by 20 shr eax,20 which makes eax 0 and the divisor ebp is also 0 so div eax, ebp results in a divide by zero exception which leads to immediate termination. via msvcrt!exit at 0x......9e78
Related
there is a .NET application that seems to have memory leak in the unmanaged heap. I found a promising blog that explains how to debug the unmanaged heap and trace the heap frames up to the managed functions that caused the memory allocation (https://www.deleaker.com/blog/2021/03/19/unmanaged-memory-leaks-in-dotnet/). As I'm a first time windbg user, I decided to repeat the example shown in the blog. I copypasted the code, downloaded the debug tool package and used the windbg as suggested. Here is whgere I get stuck:
Microsoft (R) Windows Debugger Version 10.0.22000.194 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
*** wait with pending attach
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
ModLoad: 00000000`00120000 00000000`00128000 C:\<MyPath>\WinDbgTest.exe
ModLoad: 00007ffe`c4c10000 00007ffe`c4e05000 C:\WINDOWS\SYSTEM32\ntdll.dll
ModLoad: 00000000`77800000 00000000`779a3000 ntdll.dll
ModLoad: 00007ffe`c3180000 00007ffe`c31d9000 C:\WINDOWS\System32\wow64.dll
ModLoad: 00007ffe`c30d0000 00007ffe`c3153000 C:\WINDOWS\System32\wow64win.dll
ModLoad: 00000000`777f0000 00000000`777fa000 C:\WINDOWS\System32\wow64cpu.dll
ModLoad: 00000000`74890000 00000000`748e2000 mscoree.dll
ModLoad: 00000000`75e50000 00000000`75f40000 KERNEL32.dll
ModLoad: 00000000`76f40000 00000000`77154000 KERNELBASE.dll
ModLoad: 00000000`756b0000 00000000`7572a000 ADVAPI32.dll
ModLoad: 00000000`75730000 00000000`757ef000 msvcrt.dll
ModLoad: 00000000`75be0000 00000000`75c55000 SECHOST.dll
ModLoad: 00000000`76610000 00000000`766d0000 RPCRT4.dll
ModLoad: 00000000`74760000 00000000`747ed000 mscoreei.dll
ModLoad: 00000000`766d0000 00000000`76715000 SHLWAPI.dll
ModLoad: 00000000`74750000 00000000`7475f000 AppCore.dll
ModLoad: 00000000`74e30000 00000000`74e38000 VERSION.dll
ModLoad: 00000000`707a0000 00000000`70f50000 clr.dll
ModLoad: 00000000`75890000 00000000`75a26000 USER32.dll
ModLoad: 00000000`774e0000 00000000`774f8000 win32u.dll
ModLoad: 00000000`705b0000 00000000`7065b000 ucrtbase_clr0400.dll
ModLoad: 00000000`70660000 00000000`70674000 VCRUNTIME140_CLR0400.dll
ModLoad: 00000000`76ec0000 00000000`76ee3000 GDI32.dll
ModLoad: 00000000`75c60000 00000000`75d3c000 gdi32full.dll
ModLoad: 00000000`76810000 00000000`7688b000 msvcp_win.dll
ModLoad: 00000000`75a30000 00000000`75b50000 ucrtbase.dll
ModLoad: 00000000`75f50000 00000000`75f75000 IMM32.dll
ModLoad: 00000000`6f180000 00000000`7058e000 mscorlib.ni.dll
ModLoad: 00000000`76060000 00000000`76143000 ole32.dll
ModLoad: 00000000`77560000 00000000`777e2000 combase.dll
ModLoad: 00000000`76e50000 00000000`76ead000 bcryptPrimitives.dll
ModLoad: 00000000`6f0f0000 00000000`6f17a000 clrjit.dll
ModLoad: 00000000`757f0000 00000000`75886000 OLEAUT32.dll
(745c.6ac0): Break instruction exception - code 80000003 (first chance)
ntdll!DbgBreakPoint:
00007ffe`c4cb0810 cc int 3
0:005> !heap -s
************************************************************************************************************************
NT HEAP STATS BELOW
************************************************************************************************************************
NtGlobalFlag enables following debugging aids for new heaps:
stack back traces
LFH Key : 0xca6fcf0f30c2eb6b
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-------------------------------------------------------------------------------------
0000000001db0000 08000002 60 32 60 11 5 1 0 0
0000000000150000 08008000 64 4 64 2 1 1 0 0
-------------------------------------------------------------------------------------
0:005> !heap -stat -h 0000000001db0000
heap # 0000000001db0000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
2094 1 - 2094 (48.69)
838 1 - 838 (12.28)
800 1 - 800 (11.96)
120 5 - 5a0 (8.41)
1d8 2 - 3b0 (5.51)
100 3 - 300 (4.48)
238 1 - 238 (3.32)
50 4 - 140 (1.87)
42 3 - c6 (1.16)
3c 2 - 78 (0.70)
62 1 - 62 (0.57)
48 1 - 48 (0.42)
30 1 - 30 (0.28)
28 1 - 28 (0.23)
10 1 - 10 (0.09)
4 1 - 4 (0.02)
0:005> !heap -flt s 2094
_HEAP # 1db0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0000000001db10c0 020c 0000 [00] 0000000001db10f0 02094 - (busy)
unknown!printable
_HEAP # 150000
0:005> !heap -p -a 0000000001db10f0
address 0000000001db10f0 found in
_HEAP # 1db0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0000000001db10c0 020c 0000 [00] 0000000001db10f0 02094 - (busy)
unknown!printable
7ffec4c3b49d ntdll!RtlpAllocateHeapInternal+0x0000000000000a7d
7ffec4c5dce1 ntdll!RtlpInitEnvironmentBlock+0x0000000000000049
7ffec4ce27c1 ntdll!LdrpInitializeProcess+0x0000000000000ba1
7ffec4c84ceb ntdll!LdrpInitialize+0x000000000000015f
7ffec4c84b73 ntdll!LdrpInitialize+0x000000000000003b
7ffec4c84b1e ntdll!LdrInitializeThunk+0x000000000000000e
0:005> .load C:\<DllPath>\WinDbgDlls\sos.dll
0:005> !ip2md 7ffec4c84b1e
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of clr.dll is
in the version directory or on the symbol path
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on supported cross platform architecture as
the dump file. For example, an ARM dump file must be debugged
on an X86 or an ARM machine; an AMD64 dump file must be
debugged on an AMD64 machine.
You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.
0:005> .cordll -ve -u -l
CLR DLL status: No load attempts
Everything seems to work until I call !ip2md, here comes a "Failed to load data access DLL". Following some google results I have put the clr.dll, SOS.dll and mscordacwks.dll in one folder and made sure that they all have the same bitness and the same version.
How to proceed?
Instead of loading a specific version of SOS located somewhere on your PC, let .NET decide which version to load.
Replace
.load C:\<DllPath>\WinDbgDlls\sos.dll
by
.loadby sos clr
This tells WinDbg to load the SOS extension from whatever place CLR was loaded from. This will make sure that the versions match and the DAC matches as well.
.loadby may depend on the .NET version
.loadby sos mscorwks ; *** .NET 2
.loadby sos clr ; *** .NET 4
.loadby sos coreclr ; *** Silverlight and .NET Core
I have a .NET .86 application. I'm trying to run dumpdomain from cdb but keep getting an error.
There are a lot of questions about this, and I've tried several variations:
C:\Users\d.banks\Documents>cdb DoNothingx86.exe
Microsoft (R) Windows Debugger Version 10.0.17134.12 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: DoNothingx86.exe
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*C:\Symbols\Microsoft
*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*C:\Symbols\Microsoft
*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00000000`002d0000 00000000`002d8000 image00000000`002d0000
ModLoad: 00007ff8`4f790000 00007ff8`4f960000 ntdll.dll
ModLoad: 00000000`77af0000 00000000`77c73000 ntdll.dll
ModLoad: 00000000`6dda0000 00000000`6ddf2000 C:\WINDOWS\System32\wow64.dll
ModLoad: 00000000`6de10000 00000000`6de87000 C:\WINDOWS\System32\wow64win.dll
(3e64.e4c): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00007ff8`4f862cc0 cc int 3
0:000> .loadby sos.dll mscorwks
Unable to find module 'mscorwks'
0:000> .loadby sos mscorwks
Unable to find module 'mscorwks'
0:000> .loadby C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll mscorwks
Unable to find module 'mscorwks'
0:000> .loadby sos.dll clr
Unable to find module 'clr'
0:000> .loadby sos clr
Unable to find module 'clr'
0:000> .loadby C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll clr
Unable to find module 'clr'
0:000> .load C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll
The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll) failed, Win32 error 0n193
"%1 is not a valid Win32 application."
Please check your debugger configuration and/or network access.
0:000> .load C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll clr
The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll clr) failed, Win32 error 0n126
"The specified module could not be found."
Please check your debugger configuration and/or network access.
I've tried using the x86 debugger:
Microsoft (R) Windows Debugger Version 10.0.17134.12 X86
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: DoNothingx86.exe
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*C:\Symbols\Microsoft
*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*C:\Symbols\Microsoft
*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00930000 00938000 image00930000
ModLoad: 77af0000 77c73000 ntdll.dll
ModLoad: 77900000 779e0000 WOW64_IMAGE_SECTION
ModLoad: 733c0000 73419000 C:\WINDOWS\SysWOW64\MSCOREE.DLL
ModLoad: 77900000 779e0000 C:\WINDOWS\SysWOW64\KERNEL32.dll
ModLoad: 76a00000 76ba2000 C:\WINDOWS\SysWOW64\KERNELBASE.dll
(1e98.2bb0): Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
eax=00000000 ebx=00000000 ecx=327c0000 edx=00000000 esi=00f326e8 edi=00bd7000
eip=77b96d5c esp=00cff2e4 ebp=00cff310 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!LdrInitShimEngineDynamic+0x71c:
77b96d5c cc int 3
0:000> .loadby sos.dll mscorwks
Unable to find module 'mscorwks'
0:000> .loadby sos.dll clr
Unable to find module 'clr'
0:000> .loadby sos mscorwks
Unable to find module 'mscorwks'
0:000> .loadby sos clr
Unable to find module 'clr'
From
ModLoad: 00000000`6dda0000 00000000`6ddf2000 C:\WINDOWS\System32\wow64.dll
we can see that it's a 32 bit process, so you need 32 bit SOS. 32 bit SOS only works with 32 bit WinDbg.
For loading extensions, there are 2 commands. One is .loadby, the other is .load. For .loadby use a relative path, for .load use a full path.
For .loadby, there are 5 options:
.loadby sos mscorsvr
.loadby sos mscorwks
.loadby sos clr
.loadby sos coreclr
.loadby sos <somethingelse>
where mscorsvr is really really old (.NET CLR 1, server version), mscorwks is quite old (.NET CLR 1 and 2, but still around) , clr is common today (.NET CLR 4), coreclr might be increasing (UWP and Silverlight) and <somethingelse> is annoying (look at lm and find something that looks similar but has a number attached).
The main issue is that you're trying to load SOS when the .NET runtime is not loaded yet. Wait until .NET is loaded and then the command will work. It's certainly not possible at the initial breakpoint.
Use
sxe ld clr
sxe ld mscorwks
sxe ld coreclr
g
to let the application run until .NET is available
I am reading the book Advanced Windows Debugging: Developing and Administering Reliable, Robust, and Secure Software by Daniel Pravat and Mario Hewardt. I have questions about Chapter 2.
I am using WinDBG 10.0.19041.1 X86 on Windows 10 Pro Version 2004 build 19041.572. I built 02sample.exe with Microsoft Visual Studio Community 2019 Version 16.7.6 with the GenerateDebugInformation property set to DebugFull. I am debugging the Debug|x86 configuration of 02sample.exe.
I am reading the section in chapter 2 named Setting a Breakpoint on Access and I am seeing differences between what is in the book and what I am experiencing.
The first difference in behavior is with the following command.
0:000> dt gGlobal
This command fails with the following error.
Symbol gGlobal not found.
The following command does work.
0:000> dt 02sample!gGlobal
*** WARNING: Unable to verify checksum for 02sample.exe
gGlobal
+0x000 m_ref : 0n0
The next difference in behavior is with the following command.
0:000> ba w4 gGlobal+0
Based on the following output, this appears to work.
0:000> bl
0 e Disable Clear 00969130 w 4 0001 (0001) 0:**** 02sample!gGlobal
However, the breakpoint is not being hit. I cannot figure out why.
Symbols Are probably Not Yet Loaded
try either .reload /f or .reload /f foo.exe
before attempting unqualified dt gGlobal
a qualified foo!gGlobal will always work because it loads the symbols
check with !sym noisy
0:000> !sym noisy
noisy mode - symbol prompts off
0:000> dt gGlobal
Symbol gGlobal not found.
0:000> dt gGlobal
Symbol gGlobal not found.
0:000> dt gGlobal
Symbol gGlobal not found.
0:000> dt awd!gGlobal
SYMSRV: BYINDEX: 0x2
snipxxxxxxxxxxxxxxx
DBGHELP: awd - public symbols & lines
C:\Users\XXX\Desktop\awd\Chapter2\Debug\awd.pdb
+0x000 m_ref : 0n0
0:000>
how is the Book Telling You to set the ba breakpoint ?
You Cannot Set a ba breakpoint on a module when you are Stopped At System Breakpoint
Because the system will reset the thread context
you have to go the Entry Point and then Set the ba breakpoint as windbg suggests do you do that ?
:\>cdb -c "g #$exentry;ba w4 awd!gGlobal;g;u .;kb;q" awd.exe |awk "/Reading/,/quit/"
0:000> cdb: Reading initial command 'g #$exentry;ba w4 awd!gGlobal;g;u .;kb;q'
*** WARNING: Unable to verify checksum for awd.exe
Breakpoint 0 hit
awd!Global::Global+0x21:
00a23461 8b45fc mov eax,dword ptr [ebp-4]
00a23464 83c404 add esp,4
00a23467 3bec cmp ebp,esp
00a23469 e895ddffff call awd!ILT+510(__RTC_CheckEsp) (00a21203)
00a2346e 8be5 mov esp,ebp
00a23470 5d pop ebp
00a23471 c3 ret
00a23472 cc int 3
ChildEBP RetAddr Args to Child
0026f9d4 00a21687 0026f9ec 522c59df 00a21670 awd!Global::Global+0x21
0026f9dc 522c59df 00a21670 00a2b208 0026fa50 awd!`dynamic initializer for 'gGlobal''+0x17
0026f9ec 00a24a5e 00a2b000 00a2b30c 91b61bad ucrtbased!_initterm+0x3f
0026fa50 00a2498d 0026fa60 00a24d08 0026fa6c awd!__scrt_common_main_seh+0xbe
0026fa58 00a24d08 0026fa6c 7683ed6c 7ffde000 awd!__scrt_common_main+0xd
0026fa60 7683ed6c 7ffde000 0026faac 773337eb awd!wmainCRTStartup+0x8
0026fa6c 773337eb 7ffde000 761f96f6 00000000 kernel32!BaseThreadInitThunk+0xe
0026faac 773337be 00a21145 7ffde000 00000000 ntdll!__RtlUserThreadStart+0x70
0026fac4 00000000 00a21145 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b
quit:
if by chance you misunderstood entrypoint to wmain() and set a ba break on reaching wmain() it probably will never be hit because the code in question has already been executed
I have a fresh copy of Windbg (x86) and wrote a simple Hello World program to test out the debugger. There is a problem when loading the executable or attaching the process, the debugger never steps into the process.
Here for example are the addresses:
ModLoad: 013c0000 013c6000 Hello World.exe
ModLoad: 76eb0000 77030000 ntdll.dll
ModLoad: 75ab0000 75bc0000 C:\Windows\syswow64\kernel32.dll
ModLoad: 74d60000 74da7000 C:\Windows\syswow64\KERNELBASE.dll
ModLoad: 70980000 70a6e000 C:\Windows\SysWOW64\MSVCR120.dll
After loading the process, I step through with F11 (Step into) to see every instruction being executed. From what I've noticed, Windbg never shows the instructions for Hello World.exe even though it does execute it.
What could be the problem and how would I go about solving it?
If you start stepping Open Executable you will have a “long way to go”, because it starts inside windows code.
Use the X command to find the main address, the names can vary a bit depending on the tool you use to make the program, but try with wildcard *main*
You can set a break in main in your program and enter g (go), from here you can step insider your code. Here is a sample for my SimpleCrash.exe
000> x SimpleCrash!*main*
*** WARNING: Unable to verify checksum for SimpleCrash.exe
011e8020 SimpleCrash!__native_dllmain_reason = 0xffffffff
011e8138 SimpleCrash!mainret = 0n0
011e1a00 SimpleCrash!wmain (int, wchar_t **)
0:000> bp 011e1a00
0:000> g
Breakpoint 0 hit
eax=00419ed8 ebx=7efde000 ecx=00417f10 edx=00000001 esi=00000000 edi=00000000
eip=011e1a00 esp=0030f9dc ebp=0030fa28 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
SimpleCrash!wmain:
011e1a00 55 push ebp
Here I’m in my SimpleCrash main function and can observe the stack into windows code
0:000> k
ChildEBP RetAddr
0030f9d8 011e1959 SimpleCrash!wmain
0030fa28 011e1b4d SimpleCrash!__tmainCRTStartup+0x199 [f:\dd\vctools\crt_bld\s
0030fa30 7548336a SimpleCrash!wmainCRTStartup+0xd [f:\dd\vctools\crt_bld\self_
0030fa3c 77859f72 kernel32!BaseThreadInitThunk+0xe
0030fa7c 77859f45 ntdll!__RtlUserThreadStart+0x70
0030fa94 00000000 ntdll!_RtlUserThreadStart+0x1b
I'm trying to discover the WinDbg tool to analyze a crash dump we have on our production server.
When I run !analyze -v, I get:
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
GetPageUrlData failed, server returned HTTP status 404
URL requested: http://watson.microsoft.com/StageOne/w3wp_exe/7_0_6002_18005/49e03238/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1
FAULTING_IP:
+14935130
00000000`00000000 ?? ???
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000000000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0
FAULTING_THREAD: 00000000000029b0
DEFAULT_BUCKET_ID: WRONG_SYMBOLS
PROCESS_NAME: w3wp.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
MOD_LIST: <ANALYSIS/>
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
MANAGED_STACK: !dumpstack -EE
OS Thread Id: 0x29b0 (0)
Child-SP RetAddr Call Site
PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS
BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS
LAST_CONTROL_TRANSFER: from 000000007749c0b0 to 00000000775e6d5a
STACK_TEXT:
00000000`0012f6c8 00000000`7749c0b0 : 00000000`00000000 000007fe`faf07e6b 00000000`00000000 000007fe`f9c015f0 : ntdll!ZwWaitForSingleObject+0xa
00000000`0012f6d0 000007fe`f9c03e74 : 00000000`00000158 00000000`ffb35de0 00000000`00000000 00000000`00000158 : kernel32!WaitForSingleObjectEx+0x9c
00000000`0012f790 00000000`ffb3235a : 00000000`fffffffe 00000000`00000001 00000000`007e6400 00000000`0000008c : w3wphost!AppHostInitialize+0x280
00000000`0012f7f0 00000000`ffb33b71 : 00000000`00000000 00000000`ffb33ce5 00000000`00000000 00000000`00000000 : w3wp!wmain+0x466
00000000`0012f980 00000000`7748be3d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : w3wp!PerfStopProvider+0x199
00000000`0012f9c0 00000000`775c6a51 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`0012f9f0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d
STACK_COMMAND: ~0s; .ecxr ; kb
FOLLOWUP_IP:
w3wphost!AppHostInitialize+280
000007fe`f9c03e74 f6052998000003 test byte ptr [w3wphost!g_dwDebugFlags (000007fe`f9c0d6a4)],3
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: w3wphost!AppHostInitialize+280
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: w3wphost
IMAGE_NAME: w3wphost.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 49e0420f
FAILURE_BUCKET_ID: WRONG_SYMBOLS_80000003_w3wphost.dll!AppHostInitialize
BUCKET_ID: X64_APPLICATION_FAULT_WRONG_SYMBOLS_w3wphost!AppHostInitialize+280
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/w3wp_exe/7_0_6002_18005/49e03238/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1
Followup: MachineOwner
I really have a hard time figuring what is what. From what I understand, here are the interesting part:
EXCEPTION_CODE and STACK_TEXT.
I'm a really new to WinDbg, and it's the first time I'm using this tool. I've been struggling with my Google search, so I guess I'm not searching for the right thing.
What I'd like to do is:
Understand the output format of the stack_text
Try to see the input parameters of each functions
Is that the right way to approach this problem?
There are several good tutorials available on the web and even in the WinDbg help file (.chm). A good place would be WinDBG tutorial - Introduction or Tess' blog, If broken it is, fix it you should.
In your case, step 1 would be to point WinDbg to the correct symbols. It's clear from the output above that your sympath is either incorrect or not pointing to any PDB files. Do the following in the debugger:
.sympath SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
This will point the debugger to use the Microsoft public symbol server for OS components; it will cache the PDB files to your c:\symbols folder. To add another symbol path (for example, the folder containing your application's PDB files), you can either use a ';' delimited list of paths or simply use the .sympath+ command to add new paths piecemeal.
Once you set up your symbol path, run !analyze -v again or follow the steps in the tutorial above to see if you get better results.
The stack trace should be readable if you have the correct symbols. You could try something like:
Load the dump file.
Run .symfix
Open the 'Symbol File Path' menu
Add a path to your application's .PDB files
Check the 'reload' checkbox
Run !clrstack -p to dump the stack with parameters.