Debugging using windbg preview


Supported Operating Systems

Удаленный компьютер должен работать под управлением одной из следующих операционных систем:

  • Windows 10 (не телефон)

  • Windows 8 или 8.1 (не телефон)

  • Windows 7 с пакетом обновления 1 (SP1)

  • Windows Server 2016

  • Windows Server 2012 или Windows Server 2012 R2

  • Windows Server 2008 с пакетом обновления 2 (SP2), Windows Server 2008 R2 с пакетом обновления 1 (SP1)


Для отладки Windows Phone требуется USB-подключение (инструменты удаленной отладки не требуются).

Поддерживаемые конфигурации оборудования

  • Процессор с тактовой частотой 1,6 ГГц или большей

  • 1 ГБ ОЗУ (1,5 ГБ при выполнении в виртуальной машине)

  • 1 ГБ доступного пространства на жестком диске

  • Жесткий диск 5400 об/мин

  • Видеоадаптер с поддержкой DirectX 9 и разрешением экрана 1024×768 или выше

Конфигурация сети

Удаленный компьютер и компьютер Visual Studio должны быть подключены по сети, объединены в рабочую или домашнюю группу либо соединены напрямую с помощью кабеля Ethernet. Отладка между двумя компьютерами, подключенными через прокси-сервер, не поддерживается. Отладка через подключение с высокой задержкой или низкой пропускной способностью, например при подключении к Интернету по коммутируемой линии или при размещении компьютеров в разных странах, может приводить к сбоям или работать недопустимо медленно и поэтому не рекомендуется.

WinDbg Features

Debugger Extension DLLs

Debugger extensions are DLLs that you can hook up with a debugger to execute custom commands from within the debugger. There are certain functions that a DLL needs to implement and some requirements that a DLL needs to meet in order to qualify as an extension DLL. In the next article, we shall learn how to write an extension DLL yourself. The bang (!) commands are commands executed from your extension DLLs. Note that extension DLLs are loaded in the process space of the debugger.

Dump Files

You can take snapshot information of a process using the dump facility. A mini-dump is usually small, unless you take a full-memory minidump (.dump /mf). It is useful to dump handle information also, as .dump/mfh. A mini-dump contains information about all threads including their stacks and list of loaded modules. A full dump contains more information, like that of the process heap.

Crash Dump Analysis

If your Windows OS crashes, it dumps the physical memory contents and all process information to a dump file, configured through System->Control Panel->Advanced->’Startup and Recovery’. It is also possible to take dumps of any live process by breaking into it. You can also take a dump of any process (.dump) that terminates abnormally by configuring WinDbg as a JIT debugger. Note that figuring out bugs in the code from a crash dump could be an involved process.

To analyze a dump, follow these steps:

Step 1: In WinDbg, File->’Open Crash Dump’, and point to the dump file

Step 2: WinDbg will show you the instruction your app was executing when it crashed.

Step 3: Set your symbol path and source path properly. If you cannot match symbols, you could have a hard time figuring out control flow. If you can match the symbols to source code of the appropriate version, it should be easy to figure out the bug at this point. Note that private symbol files have line number information and will blindly show the line in your source code without further checks; if your source is not version-matched properly, you’d not see the correct source code matching the assembly code. If you have public PDB files, you’ll see the last public function (on the call stack) that was invoked.

Note that debugging drivers or managed code is much different. Refer to for debugging techniques for device drivers.


  • Performance
    • CPU usage (current, max, chart)
    • Memory usage (current, max, chart)
    • FPS (current, min, chart)
    • Widget displaying current CPU usage, memory usage and FPS that stays on top of the screen
    • Simulating memory warning
  • User interface
    • Showing all view frames
    • Slowing down animations
    • Showing touches on screen (useful for recording and screen sharing)
    • Displaying customizable grid overlay on top of the screen
    • Autolayout trace
    • Current view description
    • View controllers hierarchy
    • List of available fonts with preview
    • Showing UIDebuggingInformationOverlay
  • Network
    • List of all the requests sent by the application
    • Request and response preview
  • Resources
    • File system: browsing and removing selected files
    • User defaults: browsing, removing selected item and clearing all the data
    • Keychain: browsing, removing selected item and clearing all the data
    • Core Data: browsing all the managed objects and their relationships with sorting and filtering options
    • Cookies: browsing, removing selected cookie and clearing all the data
  • Console
    • Displaying console output in text view
    • Sending console output by email with device and system information
  • Simulating location
  • Crash reports
    • List of all the crashes
    • Crash reports containing details, stack trace, console output and a screenshot
    • Sending crash reports by email
  • Modifying custom variable values from the menu
  • Adding custom actions to the menu
  • Opening application settings
  • Application shortcut item for clearing data
  • Showing version & build number
  • Showing device model & iOS version



pod "DBDebugToolkit"

However, to provide some of its features, DBDebugToolkit does use private API. The code that uses it is obfuscated to minimize the risk of rejecting your application on the App Store, but it can not be guaranteed that it is enough. That being said, here are some safer ways to install DBDebugToolkit:

  • Adding it only to debug builds

    It is now possible to specify the build configuration for a given pod:

    pod "DBDebugToolkit", :configurations => 'Debug'

    After such setup, all your code using DBDebugToolkit needs to be placed in preprocessor macros:

    #if DEBUG
        import DBDebugToolkit
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: ?) -> Bool {
        #if DEBUG
        return true

    The one major drawback of such setup is the fact that it won’t include DBDebugToolkit in the builds that you send to the testers.

  • Creating a separate target for App Store releases

    After creating a separate target for App Store releases, your podfile could be defined this way:

    def common_pods
      # Here are all the pods that will be used in both targets.
    target 'YourApplication' do
    target 'YourApplicationAppStore' do
        pod "DBDebugToolkit"

    Then you will have to differentiate between the targets in code. To do this, you could add a custom flag to your App Store target build configuration. Assuming that you named the flag , all the code using DBDebugToolkit will be placed in preprocessor macros:

    #if !(APPSTORE)
        import DBDebugToolkit
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: ?) -> Bool {
        #if !(APPSTORE)
        return true

The setup with a separate target for App Store releases will help you prevent sending the build containing the private API calls included in DBDebugToolkit to the App Store review. However, you would have to remember about adding all the files to both targets during development. You will have to decide which way is the best for your project. Perhaps it will be easier to manually remove DBDebugToolkit from the podfile before each App Store release.


To integrate DBDebugToolkit into your Xcode project using Carthage, specify it in your Cartfile:

github "dbukowski/DBDebugToolkit" ~> 0.6.

Run carthage update to build the framework and drag the built DBDebugToolkit.framework into your Xcode project.


Or clone this repository locally by running the commands:

Then, run or to install it on development mode.

from debug_tools import getLogger

# Enable debug messages: (bitwise)
# 0   - Disabled debugging.
# 1   - Basic logging messages.
# 2   - AgentPlayer       class' notices.
# 4   - StickIntelligence class' notices.
# 127 - All debugging levels at the same time.
log = getLogger( 127, __name__ )
log( 1, "Debugging" )

Cleaning the log file every start up

If you are logging the debug output to a file and you would like to clean/erase all the log file contents,
every time you re-create the logger,
you need first to unlock the log file lock, otherwise,
the file contents are not going to be erased.

To unlock your log file,
you just need to call ,
with an empty string before creating a new logger.

On Sublime Text, this could be done with te following:

from debug_tools import getLogger
log = getLogger(debug_enabled, "wrap_plus", "wrapplus.txt", mode='w')

def plugin_unloaded():

Dynamically Reloading It

If you want to reload the debug tools code on the fly, you can use this to import it:

import imp
import debug_tools.logger

imp.reload( debug_tools.logger )
from debug_tools.logger import Debugger
from debug_tools.logger import getLogger

log = getLogger(1, "LSP")

Using file logger configuration

If you want to load the logger configuration from a file, you need to replace the standard logging
module class with this one:

SysInternals Suite

Sysinternals is a suite of utilities to troubleshoot and monitor Windows software. It includes some of the most important tools we need for debugging. I suggest downloading the entire suite and saving somewhere easily typed from the command line, like . There are dozens of tools, some more useful than others. Let’s list a few of the most important ones for .NET:

Process Explorer

Process Explorer is like the Windows Task Manager on steroids. It has a myriad of features useful for debugging. Here are some of them:

  • View loaded modules
  • View handles
  • Create Dumps
  • View process tree
  • View performance counters

Process Monitor

Process Monitor, also known as ProcMon, allows you to monitor processes activity events. Specifically, you can see Registry events, File events, Network events, Thread activity, and Profiling events. If you want to find out which files or registry values your process touched, then ProcMon is the tool to help you.


ProcDump is a command-line tool for saving dump files. It can generate dumps immediately or on triggers. For example, creating a dump on a crash or a hang. It’s my recommended tool of choice for capturing dumps. Here are some of its abilities:

  • Create a Dump immediately
  • Create several dumps with specific intervals (like 3 dumps, 5 seconds apart)
  • Create dump once a CPU threshold has passed
  • Create dump if a process is hanged
  • Create dump on crash

To find out more about ProcDump and Dumps, see my article: How to Create, Use, and Debug .NET application Crash Dumps in 2019.

Загрузите и замените файл debug.exe

Последнее решение — вручную загрузить и заменить файл debug.exe в соответствующей папке на диске. Выберите версию файла, совместимую с вашей операционной системой, и нажмите кнопку «Скачать». Затем перейдите в папку «Загруженные» вашего веб-браузера и скопируйте загруженный файл debug.exe.

Перейдите в папку, в которой должен находиться файл, и вставьте загруженный файл. Ниже приведен список путей к каталогу файлов debug.exe.

  • Windows 10: C:\Windows\System32\
  • Windows 8: 1: C:\Windows\System32\
  • Windows 8.1: —
  • Windows XP: —

Если действия не помогли решить проблему с файлом debug.exe, обратитесь к профессионалу. Существует вероятность того, что ошибка (и) может быть связана с устройством и, следовательно, должна быть устранена на аппаратном уровне. Может потребоваться новая установка операционной системы — неправильный процесс установки системы может привести к потере данных.


PerfView is an open-source general-purpose analysis tool. It has a ton of things it can do, here are some of them:

  • Performance Profiling
  • Memory Profiling
  • Analyze ETW events
  • Import performance snapshots from Linux
  • Various reports on application behavior, including JIT Compilation times, Garbage collection times, and others

Its analysis is based on Event Tracing for Windows (ETW) events. This is a built-in logging system that’s extremely fast and used by every part of Windows. Everything logs events to ETW, including the Kernel, Windows OS, the CLR runtime, IIS, ASP.NET framework, WPF, and more.

PerfView is easily the most complicated tool on this list. But it’s also very powerful. To get started with PerfView, I suggest watching Vance Morrison’s video lessons series on Channel 9.

When the add-in is running in Microsoft Edge

When the add-in is running in Microsoft Edge, UI-less code will not be able to attach to a debugger by default.
UI-less code is any code running while the task pane is not visible, such as add-in commands. To enable debugging, you need to run the following Windows PowerShell commands.

  1. Run the following command to get information for the Microsoft.Win32WebViewHost app package.

    The command lists app package information similar to the following output.

  2. Run the following command to enable debugging. Use the value for the PackageFullName listed from the previous command.

  3. If Office was already running, close and restart Office so that it picks up the debugging change.

Debug using Microsoft Edge DevTools

When the add-in is running in Microsoft Edge, you can use the Microsoft Edge DevTools.

  1. Run the add-in.

  2. Run the Microsoft Edge DevTools.

  3. In the tools, open the Local tab. Your add-in will be listed by its name.

  4. Click the add-in name to open it in the tools.

  5. Open the Debugger tab.

  6. Choose the folder icon above the script (left) pane. From the list of available files shown in the dropdown list, select the JavaScript file that you want to debug.

  7. To set a breakpoint, select the line. You will see a red dot to the left of the line and a corresponding line in the Call stack (bottom right) pane.

  8. Execute functions in the add-in as needed to trigger the breakpoint.

Установка Debugging Tools for Windows с ISO-образа Windows SDK

Данный метод подразумевает установку Debugging Tools for Windows с использованием полного инсталляционного образа Windows SDK (Software Developers Kit). До определенного времени, скачать образ ISO для соответствующей системы можно было на странице Архив Windows SDK . Однако, в данный момент, получить ISO-образ SDK можно через запуск web-инсталлятора sdksetup.exe
, и выбора пункта Download the Windows Software Development Kit
в стартовом окне инсталлятора:

Соответственно, на странице необходимо подобрать требуемый дистрибутив, для меня (да и думаю для многих) в данный момент это «Пакет Windows SDK для Windows 7 и.NET Framework 4» и чуть ниже нажать на ссылку «Получить ISO-образ DVD-диска».

Соответственно, необходимо выбрать исключительно по необходимости. Обычно разрядность Debugging Tools for Windows совпадает с разрядностью системы. У меня исследуемые системы, в основном, 64-битные, поэтому я в большинстве случаев скачиваю образ для 64-битной системы GRMSDKX_EN_DVD.iso
Затем, после скачивания образа, нам необходимо с имеющимся ISO-образом как-то работать. Традиционным способом является, конечно же, запись компакт-диска, но ведь это достаточно долгий и иногда затратный метод. Предлагаю воспользоваться бесплатными утилитами по созданию в системе виртуальных дисковых устройств. Лично я для этой цели предпочитаю пользоваться программой DEAMON Tools Lite . У кого-то могут быть и другие предпочтения, более прямые или легковесные утилиты, на вкус и цвет, как говорится.. После инсталляции DAEMON Tools Lite, я просто щелкаю два раза на файл образа GRMSDKX_EN_DVD.iso
и в системе у меня появляется новый виртуальный компакт диск:

Что такое файл DMP?

Файл «.dmp» содержит сообщение об ошибке, список драйверов, загруженных во время сбоя, а также сведения о ядре, процессоре и процессах.

Windows 10 создает файлы дампа автоматически, но в самой ОС нет никаких встроенных инструментов, которые смогли бы откырть файл дампа. Чтобы открыть dmp-файл мы воспользуемся программой Microsoft WinDbg.

WinDbg (отладка Windows) — это инструмент, который был разработан для отладки кода в режиме ядра и в режиме пользователя, проверки реестров процессора и анализа аварийных дампов.

В этом руководстве по Windows 10 мы покажем вам, как открыть файл дампа, чтобы попытаться выяснить, что вызвало сбой, чтобы решить проблему на вашем компьютере.

Tracing the execution

Now it’s time to trace the script.

There are buttons for it at the top of the right panel. Let’s engage them.

– “Resume”: continue the execution, hotkey F8.

Resumes the execution. If there are no additional breakpoints, then the execution just continues and the debugger loses control.

Here’s what we can see after a click on it:

The execution has resumed, reached another breakpoint inside and paused there. Take a look at the “Call Stack” at the right. It has increased by one more call. We’re inside now.

– “Step”: run the next command, hotkey F9.

Run the next statement. If we click it now, will be shown.

Clicking this again and again will step through all script statements one by one.

– “Step over”: run the next command, but don’t go into a function, hotkey F10.

Similar to the previous “Step” command, but behaves differently if the next statement is a function call. That is: not a built-in, like , but a function of our own.

The “Step” command goes into it and pauses the execution at its first line, while “Step over” executes the nested function call invisibly, skipping the function internals.

The execution is then paused immediately after that function.

That’s good if we’re not interested to see what happens inside the function call.

– “Step into”, hotkey F11.

That’s similar to “Step”, but behaves differently in case of asynchronous function calls. If you’re only starting to learn JavaScript, then you can ignore the difference, as we don’t have asynchronous calls yet.

For the future, just note that “Step” command ignores async actions, such as (scheduled function call), that execute later. The “Step into” goes into their code, waiting for them if necessary. See for more details.

– “Step out”: continue the execution till the end of the current function, hotkey Shift+F11.

Continue the execution and stop it at the very last line of the current function. That’s handy when we accidentally entered a nested call using , but it does not interest us, and we want to continue to its end as soon as possible.

– enable/disable all breakpoints.

That button does not move the execution. Just a mass on/off for breakpoints.

– enable/disable automatic pause in case of an error.

When enabled, and the developer tools is open, a script error automatically pauses the execution. Then we can analyze variables to see what went wrong. So if our script dies with an error, we can open debugger, enable this option and reload the page to see where it dies and what’s the context at that moment.

Continue to here

Right click on a line of code opens the context menu with a great option called “Continue to here”.

That’s handy when we want to move multiple steps forward to the line, but we’re too lazy to set a breakpoint.

Наиболее распространенные проблемы с файлом debug.exe

Существует несколько типов ошибок, связанных с файлом debug.exe. Файл debug.exe может находиться в неправильном каталоге файлов на вашем устройстве, может отсутствовать в системе или может быть заражен вредоносным программным обеспечением и, следовательно, работать неправильно. Ниже приведен список наиболее распространенных сообщений об ошибках, связанных с файлом debug.exe. Если вы найдете один из перечисленных ниже (или похожих), рассмотрите следующие предложения.

  • debug.exe поврежден
  • debug.exe не может быть расположен
  • Ошибка выполнения — debug.exe
  • Ошибка файла debug.exe
  • Файл debug.exe не может быть загружен. Модуль не найден
  • невозможно зарегистрировать файл debug.exe
  • Файл debug.exe не может быть загружен
  • Файл debug.exe не существует


Не удалось запустить приложение, так как отсутствует файл debug.exe. Переустановите приложение, чтобы решить проблему.

Проблемы, связанные с debug.exe, могут решаться различными способами. Некоторые методы предназначены только для опытных пользователей. Если вы не уверены в своих силах, мы советуем обратиться к специалисту

К исправлению ошибок в файле debug.exe следует подходить с особой осторожностью, поскольку любые ошибки могут привести к нестабильной или некорректно работающей системе. Если у вас есть необходимые навыки, пожалуйста, продолжайте

Как удалить этот файл

Если пользователю понадобилось удалить minidump, то выполняет он эту процедуру ручным способом. А именно: перейти по пути месторасположения файлов на диске: C:\Windows\Minidump. Для удаления элементов minidump в каталоге Windows нужно воспользоваться встроенным инструментом системы «Очистка диска»:

  • Вызвать командную строку.
  • Ввести команду Cleanmpg.

  • Тапнуть по кнопке очищения системных файлов.
  • Найти в списке объекты, касающиеся мини-дампа, поставить галочки.
  • Начнется удаление, которое потребует некоторое время.

Если в списке нужных объектов не нашлось, это не означает, что они отсутствуют в системе. Скорей всего, они отключены пользователем или программами по очистке.

Дамп памяти в ОС Windows 10 – инструмент, помогающий диагностировать и устранять причины сбоев и появление BSoD. Если автоматическое создание и сохранение дампов памяти отключено, рекомендуется активировать их. Чаще причиной отключения файлов становятся утилиты для очистки ПК и оптимизации работы системы.

Getting the Symbols You Need

Visual Studio and other Microsoft debuggers, such as WinDbg, are typically set up to just work if you are building an application and debugging it on your own computer. If you need to give your executable to someone else, if you have multiple versions of a DLL or an .exe file on your computer, or if you want to accurately debug an application that uses Windows or other libraries, such as DirectX, you need to understand how debuggers find and load symbols. The debugger uses either the symbol search path that is specified by the user—which is found in Options\Debugging\Symbols in Visual Studio—or the _NT_SYMBOL_PATH environment variable. Typically, the debugger searches for matching PDBs in the following locations:

  • The location that is specified inside the DLL or the executable file.

    If you have built a DLL or an executable file on your computer, by default the linker places the full path and file name of the associated PDB file inside the DLL or the executable file. When you debug, the debugger first checks to see if the symbol file exists in the location that is specified inside the DLL or the executable file. This is helpful, because you always have symbols available for code that you have compiled on your computer.

  • PDBs that may be present in the same folder as the DLL or executable file.

  • Any local symbol cache folders.

  • Any local network file share symbol servers.

  • Any Internet symbol servers, such as the Microsoft symbol server.

To make sure that you have all the PDBs that you need for accurate debugging, install the debugging tools for Windows. The 32 and 64 bit versions can be found at Debugging Tools for Windows.

A useful tool that is installed with this package is symchk.exe. It can help to identify missing or incorrect symbols. This tool has a large number of potential command line options. Here are two of the more useful and commonly used ones.

Check if all the DLLs and executable files in a set of folders have matching PDBs

The /r option sets symchk to recursively traverse through folders, to check that all the executable files have matching PDBs. Without the /s option, symchk uses the current _NT_SYMBOL_PATH to search for symbols on any private or local server, or on the Microsoft symbol servers. The symchk tool searches only for symbols for executable files (.exe, .dll, and similar). You cannot use wild cards search for symbols for non-executable files.

How symchk Works

When the linker generates .dll, executable, and PDB files, it stores identical GUIDs in each file. The GUID is used by tools to determine if a given PDB file matches a DLL or an executable file. If you alter a DLL or an executable file—by using a resource editor or copy protection encoding, or by altering its version information—the GUID is updated and the debugger cannot load the PDB file. For this reason, it’s very important to avoid manipulating the DLL or executable file after it is created by the linker.

You can also use the DUMPBIN utility that comes with VS.NET to show the symbol paths that are searched, and to see if symbol files are found that match a given DLL or executable file. For example: