Windbg.exe Download Windows 10

[Nathen Paisley]

Ifyou have read any of my posts you have probably noticed that I am very partial to windbg and the debugging tools for windows. I often get friendly nudges from the developers of debugdiag when I suggest using adplus and windbg on internal discussion lists, and to be fair I have to beat on the drum a bit for debug diag as well.

Before I start the comparison, I just want to mention that dumps created with debug diag can be analysed in windbg and vice versa. They use the same APIs and create the same types of memory dumps. Where they differ largely is how you configure them to gather these dumps and logs, how you analyse them in the different tools and by the fact that DebugDiag has a nice feature that allows you to monitor memory leaks in the process.

I personally use debug diag to gather dumps for native memory leaks, and I use it to analyse asp and other native issues in conjunction with windbg. For everything else I use windbg because a) I like the logs that adplus creates and b) I like the fact that I have full control and can execute any commands I want.

Debug diag needs to be installed on the production machine through the msi downloaded above. This can sometimes prove to be a problem in cases where you are not allowed to install external tools on the server.

A process crash is usually indicative of an unhandled exception occurring in a process or code running in a process that actively terminates the process. To debug a process crash, start by creating a crash rule against the process(s) in question. Similar to previous debuggers, DebugDiag will attach to a specific process (s) and will monitor the process for multiple types of exceptions or any custom breakpoints that cause the process(s) to terminate unexpectedly. When the crash occurs, a full memory dump file will be created, in the directory specified when setting up the crash rule.

The analysis produces an HTML page with all the call stacks for the threads, info about http requests etc. and for ASP it also produces the ASP call stack. In addition it gives you information about what it thinks is the problem.

If you have a managed (.net) memory leak, leak tracking will not be very useful. If you use leak tracking for a .net leak you will simply get a message that mscorwks.dll has allocated most of the memory and that you should follow up with the author of mscorwks.dll which happens to be Microsoft.

If you have a memory dump that did not have leak tracking enabled, you can still analyse it using the memory analysis script in debug diag, it will tell you some data like how much is allocated, what heaps they are on etc. but of course it can not give you the call stacks since they were not recorded in the process.

In windbg you would set up an adplus configuration file, to either log call stacks for all .net exceptions or a specific .net exceptions, or alternatively create dumps for a specific exception depending on your needs. The details on how to set this up can be found here.

In this post i want to write about using windbg and sos.dll. I often have the problem that there is a bug at a client system and the only chance to debug it is windbg (with sos.dll). Every time i do so i have to search in many posts and forums to get all the information i need. So in this post i want to summerize the things you need to do find a bug in a .net 4 application with windbg. First of all the are a x86 and a x64 version of windbg (to find out what version you need read Choosing the 32-Bit or 64-Bit Debugging Tools). The next step is to download the windows sdk. The actual version is this one (windows sdk). After installing the sdk you can start the windbg.exe (the good thing is that you can copy the windbg.exe to every client system and start immediately with the debugging). Most of the time i have a scenario where there is a bug in the application on that specific client system and i need to find where the bug is. To do so there are several steps:

If you get no error from windbg every thing is ok.When i use windbg most of the time i search for Exceptions that occur in the client application. When i have found the exception that occurs i have a clue where i have to search in my source code to find the bug. So i want that windbg stops the execution of the client application if the client application rises an exception. To do so i use Debug -> Event Filter and search for CLR exceptions and put the value Execution at Enabled. That means that windbg stops at every CLR exception.After all that work is doen we can realy start to find the bug. To do so we need some sos commands. We need:

This are the commandos i use to find the bug in the application. A list of all sos.dll commands is shown at the msdn.

Now i want to show how i use this commands to find information that gives me a hint to the code that produces the bug. To do so i have implemented a simple program that raises Exceptions in the actual thread and in a different thread.

If we want information about the class the ExceptionThrower object is generated of we can use the dumpClass command. (Here we use the EEClass address of the ExceptionThrower object that is marked strong)

Lately I have been getting more into exploit development as I needed a bit of a break from the more typical Red Team skills. Exploitation experience would help me bring more to red teams that I perform so wanted to start learning.

For this series of blog posts I aim to exploit the various functions within Vulnserver using a variety of Windows Exploitation techniques. Typically this is dont on an old box like a Windows 7 or XP, 32 bit machine. I like this approach in general for learning to do things as a beginner, but I always felt it caused a bit of a barrier moving exploits into modern Windows environments. Due to this, I will be doing them all (I plan to anyway) on a Windows 10 x64 machine.

At the start all exploit protections will be turned off for vulnserver on the Windows 10 machine. This is so that I can learn the basics without having to bypass a bunch of stuff Windows 10 does to protect binaries. After I have exploited the vulnserver mechanisms, I aim to turn on the various Windows 10 protections one by one and see what they do, and see how they can be bypassed (if I can figure it out).

Currently I have no idea if this is going to be do-able at my knowledge level, but I wanted to learn more about Windows 10 protections and finding bypasses and clear information on how they work can be difficult.

I am going to be using Commando-VM. This project is super handy for installing a bunch of tools, making windows more lightweight in general and disabling AV. This is optional and do at your own risk, installations can take forever and installing it can be a pain. If you do it, then I recommend changing the install config so that it is only getting the tools you want (WinDBG, Ghidra, Metasploit, VSCode, Unix tools, Git, Python2, Python3, ncat).

Whether you use commando or not, you will want to be disabling AV. I typically just add exceptions to folders such as my home folder, since AV will turn back on and you dont want it wiping metasploit or something and ruining your flow.

If you are using commando you can just use choco install windbg.fireeye, windbg.pykd.flare (you can find the package names here). With WinDBG and PyKd installed, to finish the mona setup you only need to do download the relevant python scripts (mona.py and windbglib.py).

Mona is an exploitation framework that is hugely helpful and does a lot of heavy lifting for us. It will be invaluable. It was originally designed for immunity, but there is a WinDBG port which can be downloaded with the following steps:

For scripting up my exploits I will be using Python 3 because tool development is dwindling on Python 2 and it makes packages a pain. To do this I downloaded a Python 3 installer from the python link above and installed, making sure to tick the box that includes it in my path.

For interaction with vulnserver you will need something like netcat or Telnet. Telnet is nice to install for windows, but I do get issues when interacting with vulnserver using telnet, for unknown reasons. If you got commando, then ncat can be installed with choco install ncat.flare.

If you are not running commando then you can download ncat by downloading Nmap (which will also package ncat in for you) windows installers from After this is downloaded and installed you should be able to run it like below:

If you do go with VSCode, I recommend installing some Python3 extensions and making Python3 your interpreter so that when you run code in VSCode it is Python3 and not Python2 (which we only have for mona to run).

I work on a language project that uses LLVM as a back-end. My primary target is Windows, and one of my many goals is to provide a first-class debugging experience for Windows developers. One thing that I ran into early is that debug support (i.e. from Visual Studio, WinDbg, and other Windows-centric debuggers) relies heavily on PDB files, either directly or (in the case of non-Microsoft tools) via DbgHelp.dll.

There are assumptions in PDB format about how types are encoded, but they seem to be a superset of C types (plus some extra CLR stuff and whatnot floating about) so if a given language can express enough of its type system in C signatures, the debuggers will Just Work.

If you use the pc-windows-msvc toolchain to compile your Rust code then the resulting binary will come with a .pdb file. If you enable debug info then LLVM will emit codeview debug info into the object files that the linker will convert into the .pdb file to improve debugging. So right now things already work fairly well, but there is still room for improvement in several areas. Mainly getting LLVM to emit better debuginfo and adding specific support in the debugger for Rust. The latter unfortunately depends on Microsoft caring enough to focus on that. LLVM support however can be improved by anyone who knows enough C++ and is willing to dive in.

3a8082e126