Debug Win32

[Irmgard Rossie]

Ive got a win32 project that I've loaded into Visual Studio 2005. I'd like to be able to print things to the Visual Studio output window, but I can't for the life of me work out how. I've tried 'printf' and 'cout

You can use OutputDebugString. OutputDebugString is a macro that depending on your build options either maps to OutputDebugStringA(char const*) or OutputDebugStringW(wchar_t const*). In the later case you will have to supply a wide character string to the function. To create a wide character literal you can use the L prefix:

You can use the _RPTn, and _RPTFn macros, defined in CRTDBG.H, to replace the use of printf statements for debugging. These macros automatically disappear in your release build when _DEBUG is not defined, so there is no need to enclose them in #ifdefs.

_CrtDbgReport and _CrtDbgReportW create the user message for the debug report by substituting the argument[n] arguments into the format string, using the same rules defined by the printf or wprintf functions. These functions then generate the debug report and determine the destination or destinations, based on the current report modes and file defined for reportType. When the report is sent to a debug message window, the filename, lineNumber, and moduleName are included in the information displayed in the window.

If you need to see the output of an existing program that extensively used printf w/o changing the code (or with minimal changes) you can redefine printf as follows and add it to the common header (stdafx.h).

Your Win32 project is likely a GUI project, not a console project. This causes a difference in the executable header. As a result, your GUI project will be responsible for opening its own window. That may be a console window, though. Call AllocConsole() to create it, and use the Win32 console functions to write to it.

I'm assuming that you started a default Win32 Project (Windows application) in Visual Studio, which provides a "WinMain" function. By default, Visual Studio sets the entry point to "SUBSYSTEM:WINDOWS". You need to first change this by going to:

There are two ways to do this: You can select a binary to run in your debugger, so you would select ableton for instance, the Debugger would start attached to Ableton, giving you the chance to debug your plugin, if you load it inside Ableton.

Well, if you are looking only for Windows 7 then you can use WinDBG debugger which is available for both 32-bit and 64-bit Windows. You have to learn it and just search on Google for WinDBG tutorial/commands and you will get them.

A very good way if you really miss it set up a virtual machine and use XP Mode in Windows 7 and you can use debug.exe in that way easily. As this question has end with the same solution of VM.

I've heard that it's in the 32 bit version of win7 but not the 64 but I can't confirm as I use 64. Are you trying to write assembly or machine code? I'm not sure what debug does, whether it's machine code or assembly. Try out WinAsm if it's assembly you're trying to learn/use. It's a free IDE I've used recently.

What you heard is right. The following is from Win 7 32bit, debug is available. Debug is not available in Win 7 64bit. Below is a screenshot from Win 7 32bit. (version of win7 tested on is win7 ultimate)

Ghidra is a cross-platform reverse-engineering and binary analysis tool, with recent versions including support for dynamic analysis. I want to try using it as a replacement for IDA Pro in reverse-engineering of Win32 binaries, but hit bugs related to address space detection when running gdbserver with Wine (ghidra#4534).

To compile a PE binary in Linux you can either use Wine to install the Windows SDK, or use a cross-compiler. The Windows SDK is a bit of a pain to install since it's distributed as an ISO image full of installer wizards, so I choose the second option. For cross-compilation I prefer to use Clang and LLD whenever possible since they're "native" cross-compilers, which means that (unlike GNU GCC/LD) their target platform can be selected at runtime.

The i686-w64-mingw32-gdb process runs in the Linux environment, and provides a REPL that can control the "remote" gdbserver. This process is necessary because Ghidra doesn't directly speak the GDB serial protocol, it controls GDB through the text UI. Before starting up Ghidra, verify that the GDB bits are working:

Create the Ghidra project, import the Win32 binary to be analyzed, and enter the Debugger tool. When connecting to GDB you can use either IN-VM or GADP, but GADP is probably better since Ghidra's debugger can get wedged and it's nice to be able to forcefully disconnect by killing the GADP agent.

Here's where things start to go wrong. After creating the trace record, Ghidra will start throwing out error popups about trying to access invalid address space. Github issue ghidra#4534 has some of the nitty-gritty details on what's going on, but in summary Ghidra depends on the GDB command info proc mappings to figure out what it can peek at, and GDB doesn't implement that command for Windows targets.

There's two problems we're facing here:First, we need to get access to the /proc/pid/maps file corresponding to the target process, parse it, and render output that matches what Ghidra expects from GDB.Second, the gdbserver is running inside Wine and therefore uses Windows process IDs. There's no way to query the Linux process ID for a Windows process; such an API obviously doesn't exist in Windows, and Wine developers have declined to implement it as an extension.

The memory map parsing/formatting sounds tricky but is actually pretty straightforward because the format of info proc maps is almost the same as what GDB provides, and Ghidra doesn't care about the differences. The GDB Python API can be used to define a new remote-proc-mappings command, which reads /proc/pid/maps for any process accessible to the remote gdbserver.

Next we need the Linux PID. Luckily(?) Wine allows Win32 binaries to directly invoke Linux syscalls via the INT 0x80 instruction, so a straightforward approach is to inject a linux_getpid() function into the target process's address space and then use GDB's call command to run it.

If the above command causes a segfault then the binary was probably compiled with /nxcompat, which places the stack in a non-executable mapping. Luckily(?) again, Windows processes map their .text segment to a fixed offset (by default 0x401000), so you can use Ghidra to locate some function padding or an unused error branch or whatever and write the getpid stub there:

Put that into a wine-win32.gdb file and source it from Ghidra's GDB interpreter panel. Note that to make Ghidra happy the info proc mappings command must be overridden before connecting to the remote gdbserver.

In this tutorial we will build GNU binutils from command line and use Visual Studio to debug the cxxfilt.exe program (GNU C++ name demangler) to find out which function inside it does the actual demangling. You can use the techniques described here to debug any other tool built with GCC.

I'm not sure if VSCODE supports the notion of pre-built Debug and Release configurations (so you don't have to completely recompile the sdk and libraries when switching from debug to release configurations), but it would be nice...

I am following up from an issue a VS Code user encountered a while back with Intel Fortran compilers on Windows and Debugging. Essentially, the problem faced was that there was no suitable Expression Evaluator for Intel compilers on Windows. Therefore, the Debug Adaptor cppvsdbg (closed-source and IP owned my Microsoft) is not capable of resolving the symbols from the object file.

I was wondering if someone from Intel could share some thoughts on this. Is Intel aware of this limitation? Would Intel consider implementing such feature for VS Code? Are there any workarounds you can suggest for your Windows users?

An increasing number of users has been posting about ifort/ifx and VS Code debugging on Windows, with the latest being visual studio code - VSCode with Intel Fortran debugger: debugging window doesn't show allocatable variables - Stack Overflow

I'm trying to use CVI to output debug messages to the Win32 debugger using OutputDebugString(). However, the debug messages are not showing up in any debugger. I can see them in the Debug Output window in CVI, but they don't show up in any debugger (DebugView, Trace Spy, Hoo WinTail, etc.) I'm showing all messages from all processes in the debugger, and I can see messages sent with OutputDebugString() from LabVIEW, but for some reason nothing shows up when I call OutputDebugString() with CVI. I've also tried all the settings in Options->Environment->Debug. I'm using CVI 10.0.0.

Only one debugger can capture the debug output of a debuggee at a time. So if you DEBUG your program from CVI, then the program's debug output can only be seen in the CVI Debug Output Window. If you RUN (Ctrl-F5) your program from CVI without debugging, then you can see the program's debug output in dbgview.

For this post I use AVG as an example, however I have tried to avoid focusing too much on this one product as many other AV solutions and security products use the exact same technique, so the same principals can be applied.

DebugActiveProcess is responsible for kicking off a debugging session with a target process, and takes the PID of the process as an argument. If we review the documentation for the call on MSDN, we come across this:

The debugger must have appropriate access to the target process, and it must be able to open the process for PROCESS_ALL_ACCESS. DebugActiveProcess can fail if the target process is created with a security descriptor that grants the debugger anything less than full access. If the debugging process has the SE_DEBUG_NAME privilege granted and enabled, it can debug any process.

ObRegisterCallbacks is something that I first came across in the gaming/modding community, where it has been used to thwart attempts to modify or inject functionality into games when bypassing anti-cheat and DRM drivers.

3a8082e126