windbg

I am trying to do Windows kernel debugging so I have set up two machines for this purpose: HOST - DEBUGGER - The computer that runs the windbg debugger TARGET - DEBUGEE - The computer being debugged Both HOST and TARGET runs Windows 7 32 bit and both have Windows Driver Kit 8.0 installed. I did the following steps: On TARGET I've enabled kernel debugging with following commands: bcdedit /copy {current} /d "Windows 7 wih debug" bcdedit /debug {02b760e4-eafc-11e4-8847-ac1155aec81a} on bcdedit /dbgsettings serial debugport:1 baudrate:115200 bcdedit /set {bootmgr} displaybootmenu yes bcdedit

I am using WinDbg to look into a process dump. The dump has been taken on an x86 server with .NET 4 SP1 (4.0.30319.237). I'm attempting to debug on my x64 machine using the x86 version of WinDbg, but I get the following issue. 0:000> !EEVersion The version of SOS does not match the version of CLR you are debugging. Please load the matching version of SOS for the version of CLR you are debugging. CLR Version: 4.0.30319.237 SOS Version: 4.0.30319.239 4.0.30319.237 retail Workstation mode SOS Version: 4.0.30319.239 retail build As my machine has taken a recent security patch, the SOS DLL file is

hi i have attached crash dump for an exe and symbols also.but i am getting this error: Unable to verify checksum for abc.exe. What would be the reason for this? Unable to verify checksum is emitted when the checksum in pe header isnt verifiable this can happen if the exe in question was compiled and linked without using /RELEASE linker option normal project based compile link sets this option nmake / batfile based compilation can omit this switch and can lead to this output a simple helloworld compiled and linked with and without /RELEASE Linker Option (pdb not generated for simpilicity and

I have a crash dump for a customer's application built with a very old version of our dll (release build, don't have original symbols) that I've been analyzing in WinDbg. In order to get more information, I rebuilt the dll in release mode, with symbols this time, using the same compiler version and I believe the same settings as when the dll was originally built. I added the symbol file to my symbol path, but the WinDbg extension !itoldyouso tells me the module in the dump doesn't match the PDB file. Enabling SYMOPT_LOAD_ANYTHING doesn't help either. !itoldyouso tells me they don't match

While trying to track down a fatal null pointer language exceptions (c000027b) in a UWP C#/XAML store project with WinDbg, I cannot get to the CLR Exception object because of a missing SOS debugging extention for Microsoft.NET.CoreRuntime. I was unable to locate a matching sos.dll. What am I missing? Note: The app crash is reproducible, but only happens when not debugging. So running the project under the Visual Studio debugger is unfortunately not a solutions in this case. [...] 0:009> dt -a6 000001c37c6587e0 combase!PSTOWED_EXCEPTION_INFORMATION_V2 [0] @ 000001c3`7c6587e0 -------------------

I am using Windbg to diassemble managed code (written in C#, console application) using Windbg's !U command from sos.dll. I find when using !U to diassemble a managed function, the diassembled IL code only contains function calls I made, and for remaining parts (non-function call C# code), for example a=a*2 , and foreach loops in C#, only native assembly language code is shown, is that the correct expected behavior? My question is, I want to know whether !U is capable of diassemble managed code binary DLL into IL with all code (besides function call code)? Thanks in advance, George If you want

I'm trying to get used to working with WinDbg to troubleshoot crash dumps when I'm able to get them, but every time I do it seems it's asking me for a different version of mscorwks.dll and mscordacwks.dll, and I don't always have access to the machine the dump came from. Other than telling end users they have to dig around in their Windows directory for these files on top of sending me an absurdly large "mini"-dump, is there somewhere I can get copies of different builds of these files? WinDbg doesn't seem to be able to find them through Microsoft's symbols server. You are supposed to get the