I'm pretty new to using WinDbg, but recently my application started having issues, but only on Windows 7 machines (it runs fine the first time the PC is started but crashes or just disappears silently each time after).
I got the mdmp file, but find myself somewhat lacking on how best to extract the data I need from it. I got the following analysis (might be doing it wrong)...
Can anyone hopefully help shed some light on my issue or if I'm running the analysis incorrectly:
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
GetPageUrlData failed, server returned HTTP status 404
URL requested: http://watson.microsoft.com/StageOne/Star_exe/1_0_0_0/4dbad268/KERNELBASE_dll/6_1_7600_16385/4a5bdaae/e0434352/00009617.htm?Retriage=1
FAULTING_IP:
KERNELBASE!RaiseException+58
752d9617 c9 leave
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 752d9617 (KERNELBASE!RaiseException+0x00000058)
ExceptionCode: e0434352 (CLR exception)
ExceptionFlags: 00000001
NumberParameters: 5
Parameter[0]: 80070002
Parameter[1]: 00000000
Parameter[2]: 00000000
Parameter[3]: 00000000
Parameter[4]: 57af0000
PROCESS_NAME: Star.exe
ERROR_CODE: (NTSTATUS) 0xe0434352 - <Unable to get error code text>
EXCEPTION_CODE: (NTSTATUS) 0xe0434352 - <Unable to get error code text>
EXCEPTION_PARAMETER1: 80070002
EXCEPTION_PARAMETER2: 00000000
EXCEPTION_PARAMETER3: 00000000
EXCEPTION_PARAMETER4: 0
MOD_LIST: <ANALYSIS/>
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
MANAGED_STACK: !dumpstack -EE
No export dumpstack found
MANAGED_BITNESS_MISMATCH:
Managed code needs matching platform of sos.dll for proper analysis. Use 'x86' debugger.
ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD]
LAST_CONTROL_TRANSFER: from 57c03970 to 752d9617
FAULTING_THREAD: ffffffff
DEFAULT_BUCKET_ID: STACKIMMUNE
PRIMARY_PROBLEM_CLASS: STACKIMMUNE
BUGCHECK_STR: APPLICATION_FAULT_STACKIMMUNE_NOSOS_CLR_EXCEPTION_WRONG_SYMBOLS
STACK_TEXT:
00000000 00000000 star.exe+0x0
SYMBOL_NAME: star.exe
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: star
IMAGE_NAME: Star.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4dbad268
STACK_COMMAND: ** Pseudo Context ** ; kb
FAILURE_BUCKET_ID: STACKIMMUNE_e0434352_Star.exe!Unknown
BUCKET_ID: APPLICATION_FAULT_STACKIMMUNE_NOSOS_CLR_EXCEPTION_WRONG_SYMBOLS_star.exe
FOLLOWUP_IP: *** WARNING: Unable to verify timestamp for Star.exe
Star!.ctor+0 [C:\Users\Aj\Documents\Visual Studio 2010\Projects\Star\Star\ViewModels\ViewModelBase.cs # 22]
00360000 ?? ???
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/Star_exe/1_0_0_0/4dbad268/KERNELBASE_dll/6_1_7600_16385/4a5bdaae/e0434352/00009617.htm?Retriage=1
Followup: MachineOwner
---------
You may want to use this article as a starting point: SOS: It's Not Just an ABBA Song Anymore
It looks like your application is a .NET application, make sure you've got the right .NET Framework installed. When you load the sos.dll file into windbg, you may have to provide a full path. Also, you can set up access to the public microsoft symbol servers to help with some of your stack tracing. This article may help: Debugging Tools and Symbols: Getting Started. Make sure you've got the latest version of the debugging tools.
!analyze will give you some information about the fault, but not too much else. You should look at the first article to see what else is going on.
Posting some information about your application will also help people see if you are having a similar issue.
It looks like the fault is happening in your ViewModelBase.cs file. You may want to add some logging (using log4net or similar tool) to catch the exception and print out the stack trace. You can also hook into AppDomain.CurrentDomain.UnhandledException event (or the Application.DispatcherUnhandledException event for WPF applications) to catch anything that's getting thrown and printing out something to a log file. In this case, you won't need to resort to WinDbg to figure out what's going on.
Well after several weeks of searching (maybe more), it turns out that when using Trend Micro Corporate, XP to Server 2003 is fine, Vista and Windows 7 to 2003 is fine, and even XP/Vista to server 2008 is fine, but (and I have no idea why), when using Windows 7 and trying to run a network application using a UNC path in the shortcut, it blocks certain pieces of the network traffic for that application, and it does so sporadically and what seems to be without any sound logic. I can't say why as we never quite figured out what exactly the catalyst was for setting off Trend, but I do know that when we disabled Trend, all was back to normal (something I wished we tried sooner). We found that by mapping a drive to our share and changing our shortcuts on our users workstations to use the mapped drive rather than a UNC path, the issue was averted.
Hopefully no one else runs into this problem, but if they do, this will perhaps shed some light on the issue.
Thank you!
Aj
Related
I'm very new to the C language and have been tasked with modifying GRUB. What a way to learn, right? Anyway, I'm trying to debug my modified GRUB using VMWare and GDB. I've been able to get the debugger working before, but for some reason, every time I load up my VM and connect GDB, during the loading process of GRUB, I get:
.loadsym.gdb:1: Error in sourced command file:
The address where biosdisk.module has been loaded is missing
and I have no idea what to do about it. My first thought was, "Oh, I'll just add-symbol-file <file> and that'll fix it!" but apparently that tells GDB to forget every other symbol it loaded???? So I can't add the symbol-file and set a breakpoint.
My googling only returns one semi-relevant post that doesn't really go all that in-depth on fixing the issue.
This output may also be relevant.
info file biosdisk.module
Symbols from "H:\Workspace\GRUB\Bootloader\Trunk\grub-core\kernel.exec".
Remote serial target in gdb-specific protocol:
Debugging a target over a serial line.
While running this, GDB does not access memory from...
Local exec file:
`H:\Workspace\GRUB\Bootloader\Trunk\grub-core\kernel.exec', file type elf32-i386.
Entry point: 0x9000
0x00009000 - 0x0000e6e0 is .text
0x0000e6e0 - 0x0000f68d is .rodata
0x0000f6a0 - 0x0000fe74 is .data
0x0000fe80 - 0x000175d4 is .bss
Ended up being that my codebase wasn't the same. That is, on my Windows host, I had one copy of my code and on my Ubuntu VM was another.
Using version control solved this issue.
Not totally sure that I've got this problem nailed down yet, but here's what I'm seeing and what I think is going on.
I have a Win32 program mostly written in C that loads a C++ DLL. That DLL passes data from the C program to another application via a COM object--one that's probably instantiated by the DLL itself. All of this has apparently worked fine through at least Windows XP and Windows 7 (possibly Win95 and Win98, I'd need to look back deeper into the code history to find out when this interface was introduced), but in Windows 10 the program crashes during the FreeLibrary() call for this DLL.
While checking this in the debugger, DLL_DETACH_PROCESS seems to be handled successfully (no code is executed when handling that message). The crash occurs after (or while) leaving the code from the Entry Point.
If I continue to Step In, I end up in a header file called utilcls.h, which seems to be one of the Borland C Builder 6 header files. I believe the template code therein is related to the COM object being torn down. An Unbind() call passes, and this is the last line of code I can step to before the crash.
If I use the debugger's CPU window and continue stepping, everything that remains appears to be related to freeing memory before the crash comes, but it's quite a lot of CPU-stepping to get there.
The crash raises APPCRASH with exception 0xc0000602, referring back to Combase.dll.
Simply not calling FreeLibrary for that DLL allows the application to close successfully, but my assumption is that the FreeLibrary call is important.
The COM object is released by the data-sharing application prior to the FreeLibrary() call, which allows that application to close. My assumption at the moment is that some of this unlinking is happening differently in the newer operating system and this is causing the crash, but I don't know how to be find out for sure.
My question(s):
if it's obvious to someone else who better knows what they're doing, what causes this crash?
what are the next steps in trying to debug this? I've exhausted my knowledge of the debugging environment I'm using and don't know COM or DLLs well enough to know what the next question to ask is.
Some of the debugger output RbMm requested:
0:000:x86> t
ntdll_77b40000!RtlIsCriticalSectionLockedByThread+0x1b:
77b7256b c20400 ret 4
0:000:x86> t
combase!DecrementMTAUsageHelper+0x5b:
7527a2d6 85c0 test eax,eax
0:000:x86> r eax
eax=00000001
0:000:x86> t
combase!DecrementMTAUsageHelper+0x5d:
7527a2d8 0f859a000000 jne combase!DecrementMTAUsageHelper+0xfd (7527a378) [br=1]
0:000:x86> t
combase!DecrementMTAUsageHelper+0xfd:
7527a378 e89e9e0f00 call combase!CrashProcessWithWERReport (7537421b)
At that point, the stack looks roughly like this:
ChildEBP RetAddr Args to Child
0019f9b8 7527a37c 063f4248 753d8448 00000000 combase!CrashProcessWithWERReport+0x35
0019f9e8 75292bfc 753d8448 7529257e 00000000 combase!DecrementMTAUsageHelper+0x101
(Inline) -------- -------- -------- -------- combase!DecrementMTAUsage+0x9
0019f9f0 7529257e 00000000 00000000 00000000 combase!CDllHost::MTAUninitializeApartmentOnly+0xe
0019fa08 7527543a 00000000 063f4248 00712410 combase!CDllHost::ClientCleanupFinish+0x4d
0019fa30 75276361 00000000 0019fa8c 00000000 combase!DllHostProcessUninitialize+0xa0
0019fa58 7527a452 000d06f6 00712410 00000000 combase!ApartmentUninitialize+0xe4
0019fa70 752c2a1e 000d06f6 00712e18 00712e80 combase!wCoUninitialize+0xd0
0019fa94 74ed3e58 00000003 74c17ff1 a6d0e607 combase!CoUninitialize+0x7e
0019fa9c 74c17ff1 a6d0e607 000b0792 74ed48f0 imm32!CtfImmCoUninitialize+0x48
0019fb7c 74809ea6 00050004 000d06f6 00000000 msctf!TF_Notify+0x581
0019fb98 748080dc 00050004 000d06f6 00000000 user32!CtfHookProcWorker+0x36
0019fbe0 74807fa6 0019fc34 0019fc24 00000000 user32!CallHookWithSEH+0x5c
0019fc08 77bb0006 0019fc24 00000018 0019fc80 user32!__fnHkINDWORD+0x26
0019fc38 710623fb 000b0792 04ff11aa 05480e70 ntdll!KiUserCallbackDispatcher+0x36
0019fc50 050364e4 000b0792 050376d8 05480e70 apphelp!DWM8AND16BitHook_DestroyWindow+0x2b
0019fc8c 05051007 00000000 05055034 00000001 myDLL!myCOMObject_tlbFinalize+0x408a4
0019fcb4 050511c6 0019fcd0 00000001 04ff1318 myDLL!myCOMObject_tlbFinalize+0x5b3c7
0019fcd8 04ff13d3 05055034 77badcce 04ff0000 myDLL!myCOMObject_tlbFinalize+0x5b586
0019fd00 77b807c6 04ff1318 04ff0000 00000000 myDLL+0x13d3
0019fd50 77b6aa5e 00000000 00000000 259704e5 ntdll!LdrpCallInitRoutine+0x43
0019fdb8 77b6e6c8 00000000 0071dd60 00000000 ntdll!LdrpProcessDetachNode+0xbb
0019fdd8 77b6e5af 25970745 0071e560 c000022d ntdll!LdrpUnloadNode+0x100
0019fe18 77b6e4f6 004afcc4 004ae3a4 04ff0000 ntdll!LdrpDecrementModuleLoadCountEx+0xa7
0019fe38 746e9d56 04ff0000 006e33c5 00000000 ntdll!LdrUnloadDll+0x86
0019fe4c 0049261c 04ff0000 00000000 00493034 KERNELBASE!FreeLibrary+0x16
0019fe64 00441895 004afc98 fffffffe 0019fee8 rpopdbg!_GetExceptDLLinfo+0x914bf
Working on the rest now, but my guess is I need to figure out how to do the cleanup properly on the COM object? Maybe in response to DLL_DETACH_PROCESS?
The crash raises APPCRASH with exception 0xc0000602, referring back to
Combase.dll
combase.dll used 0xc0000602 (STATUS_FAIL_FAST_EXCEPTION) code only from
void CrashProcessWithWERReport();
(which called RaiseFailFastException with this code)
CrashProcessWithWERReport called only from DecrementMTAUsageHelper on 2 conditions - CoDecrementMTAUsage called more times than CoIncrementMTAUsage or (and i almost sure in this reason) DecrementMTAUsageHelper called when calling thread hold Loader critical section - so while DLL loading or unloading process. from MSDN
Don't call CoDecrementMTAUsage during process shutdown or inside
dllmain. You can call CoDecrementMTAUsage before the call to start
the shutdown process.
so my guess - some code call CoDecrementMTAUsage in your DLL unloading process (when you call FreeLibrary)
your DLL can not direct call CoIncrementMTAUsage / CoDecrementMTAUsage because this new API, exist begin from win 8 (also check your code on win 8.1 - i think also will be crash), but this api can be indirect called from other system components.
i can assume that your DLL not direct free some used resources or you call FreeLibrary when DLL still holding some resources (so you call FreeLibrary without proper cleanup calls fro DLL) and as result this resources begin free (CoDecrementMTAUsage) in unloading process
what are the next steps in trying to debug this?
you need use debugging with symbols files (say with winDbg). set breakpoints at DecrementMTAUsageHelper, CoDecrementMTAUsage and may be CoIncrementMTAUsage - are i right that call toRtlIsCriticalSectionLockedByThread return TRUE (this api called from begin of DecrementMTAUsageHelper).
in any case post the thread call stack at DecrementMTAUsageHelper call point(just before crash) and possible on CoIncrementMTAUsage too
---------------------- EDIT -------------------------
by view stack trace visible that your DLL call DestroyWindow from DllMain.
apphelp!DWM8AND16BitHook_DestroyWindow
this is the bug just by 2 reasons - at first - read this article -
The thread that gets the DLL_PROCESS_DETACH notification is not
necessarily the one that got the DLL_PROCESS_ATTACH notification. You
can't do anything with thread affinity in your DLL_PROCESS_ATTACH or
DLL_PROCESS_DETACH handler since you have no guarantee about which
thread will be called upon to handle these process notifications. The
classic example of this, which I'm told the Developer Support team run
into with alarming frequency, is a DLL that creates a window in its
DLL_PROCESS_ATTACH handler and destroys it in its DLL_PROCESS_DETACH
handler.
but your crash here by another reason, not listed in article - DllMain have many restrictions, what can not be called inside it. despite DestroyWindow not direct listed here, but as show your case - this is illegal call (even if we called on same thread, on which this window was created) - while your window is destroyed imm32.CtfImmNotify(msctf!TF_Notify) is called
0019fa9c 74c17ff1 a6d0e607 000b0792 74ed48f0 imm32!CtfImmCoUninitialize+0x48
0019fb7c 74809ea6 00050004 000d06f6 00000000 msctf!TF_Notify+0x581
0019fb98 748080dc 00050004 000d06f6 00000000 user32!CtfHookProcWorker+0x36
0019fbe0 74807fa6 0019fc34 0019fc24 00000000 user32!CallHookWithSEH+0x5c
and as result CoUninitialize is called from DllMain !
from MSDN
do not call CoInitialize, CoInitializeEx, or CoUninitialize from the
DllMain function.
here inside FINAL CoUninitialize called DecrementMTAUsage which determinate that we inside loader lock by call RtlIsCriticalSectionLockedByThread and CrashProcessWithWERReport called.
Solution ?
of course the best is fix DLL, but if this is impossible - think next "hack" will be work
HRESULT hr = CoInitialize(0); // asume that we in STA
FreeLibrary(hDLL);
if (0 <= hr) CoUninitialize();
with this CoUninitialize of course anyway will be called from imm32!CtfImmCoUninitialize but this will be NOT FINAL Uninitialize and as result DecrementMTAUsage will be not called
I'm trying to figure out why an WPF-app won't exit imediately on closing it. Using Process Explorer I hade found out that WerFault.exe is started while exiting which seem to indicate that something crashes during the teardown, perhaps some destructor or dispose that fails. This started happening when I recently switched to VS2015. I am running Windows 8.
My question is: How can I find out what the real problem is? Any way of finding a crash log for WerFault.exe? I have hundreds of destructors and dispose-methods so it's a bit hard to put breakpoints in all of them. Any other way of capturing these kinds of errors in VS?
The exit code is -1073740791 which "indicate a bug in the executed software that causes stack overflow, leading to abnormal termination of the software". But where?
Some more info from the event log:
Faulting module name: ucrtbase.DLL, version: 10.0.10240.16390, time stamp: 0x55a5b718
Exception code: 0xc0000409
Fault offset: 0x0000000000065a4e
You could try enabling user mode dumps:
Create the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
Within LocalDumps, create a key that is the name of your executable
Within the key you just created, set the values of DumpFolder, DumpCount, DumpType, and CustomDumpFlags as needed (you should definitely set DumpType to 2 for full dumps, otherwise I don't think that enough information will be captured to debug a managed dump).
Once you have done this, whenever your executable crashes a dump file will be created in the folder specified by DumpFolder (or %LOCALAPPDATA%\CrashDumps by default).
We have a C program (a client that connects to our server). The program uses Win32 API:s to create controls etc. It is a single-threaded application. Lately the application has started to hang at random in Windows 7.
Thanks to Application Verifier, I could detect problematic APIs and rectified them.
Now there are still some customers reporting a "non-responsive" situation.
A crash dump from their side reveals the following API:
SendMessage(HWND_BROADCAST, WM_DDE_INITIATE, (WPARAM)hClient, MAKELONG(aAppl,aTopic));
Yes its sending a DDE command to WinWord.exe. Task Manager shows Winword in non-responsive state.
Evtx reveals the following:
Fault bucket , type 0
Event Name: AppHangXProcB1
Response: Not available
Cab Id: 0
Problem signature:
P1: OurApplication.exe
P2: 14.14.1.50
P3: 537337f4
P4: b6f1
P5: 32
P6: WINWORD.EXE
P7: 15.0.4615.1000
P8:
P9:
P10:
Attached files:
C:\Users\diane-do\AppData\Local\Temp\WER91C7.tmp.appcompat.txt
C:\Users\diane-do\AppData\Local\Temp\WER958F.tmp.WERInternalMetadata.xml
C:\Users\diane-do\AppData\Local\Temp\WER968B.tmp.xml
C:\Users\diane-do\AppData\Local\Temp\WER969C.tmp.hdmp
C:\Users\diane-do\AppData\Local\Temp\WER9777.tmp.mdmp
These files may be available here:
C:\Users\diane-do\AppData\Local\Microsoft\Windows\WER\ReportQueue\AppHang_OurApplication.exe_e9b582fc22d416b8787c1184f6fe7fa19d63_cab_0fde97a1
Analysis symbol:
Rechecking for solution: 0
Report Id: 9e84daa9-eff8-11e3-a2fb-90b11c841d1a
Report Status: 36
Any help would be appreciated.
Please note the above is Win 7 64-bit, while our application is 32 bit. Don't know what build their Office 2013 is (32 or 64 bit)
I am aware of the following:
- DDE is old technology, but changing it is out of question now.
- For the above case, I cant use SendMessageTimeout APIs as our client has to wait until commands complete.
ONCE AGAIN, The hang (non-responsive state) happens at random, not always at DDE but various instances. While computing something, even while doing a simple operation as below. Customers launch our CHM file from our menu, then Alt+Tab to another application and then Alt+Tab back to our application, our application becomes non-responsive.
P.S: I also didn't find any document online as to how to interpret those evtx application logs , what P1 P2 stand for. What signatures meant or what fault bucket type are, or any meaning of AppHangXProcB1 or AppHangB1 etc. Please pass the link if you have for the same.
sendmessage is a blocking call it will return only after the receiver application processes the message. Here, it got blocked & it as well blocked your application from dispatching the message. Since your application can't process any further window messages, it hanged the GUI.
Check again all the processing done on processing a window message for any blocking calls like waitforsingleobject, recv, connect in it.
I have an app running as a Windows Service. Today, I was notified that the service died. I found a event viewer entry whose basic info is: faulting module kernel32.dll, version 6.0.6002.18740, time stamp 0x50b58c3d, exception code 0xc0000005, fault offset 0x0003fc2e
I'm sure that there is a bug in my code. Can I determine the kernel32.dll function (where the exception came from) from the offset? I'm planning to backtrack to the call in my code.
I agree with what is said in the comments, but anyway I think the answer can be useful. Here is how you can find function name using Windows debugging tools from SDK provided that EventViewer reported offset of failing instruction in kernel32.dll.
First, install Windows debugging tools and configure path to Microsoft public symbol server. Instructions are available online, for example, this video: http://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-Building-your-USB-thumbdrive
Start windows debugger attached to your process or just any process in the system. kernel32.dll is one of the first DLLs any process loads, it is very unlikely that it is rebased. So kernel32.dll’s base address is the same in all processes.
Get base address of kernel32.dll by running “list modules” command in debugger
0:006> lm m kernel32
start end module name
7c800000 7c8f6000 kernel32 (pdb symbols) c:\debuggers\symbols\kernel32.pdb\A22E3A9843CC45B4A2BFA31377127D422\kernel32.pdb
So the base address is 7c800000. Now run “disassemble single instruction” command using DLL base address and offset:
0:006> u 0x7c800000+0x0003fc2e l 1
kernel32!BasepCopyFileExW+0x859:
7c83fc2e 53 push ebx
So BasepCopyFileExW is the function name. (The result on your system may be different.)