Using C + + for Windows development: Using virtual variables and format specifiers for X64 debugging

Directory

Processor architecture

Virtual variables

Format specifier

Visual calling convention

Error code

Debugging a security environment

For years, Visual C + + has included a set of virtual variables and format specifiers for debugging. A virtual variable is something that you can enter into the Debugger Watch window to display a value that does not have to be associated with any C + + variable. Unfortunately, no one has described the virtual variables in detail. My own information is not enough to describe all the virtual variables in detail, just to share with you some of the virtual variables and format specifiers that I think are most useful. I hope the discussion here will encourage you to read more about this topic.

Before introducing a virtual variable (sometimes called a pseudo register), I need to briefly describe the processor architecture and registers, because a little background knowledge will give you a better understanding of the value of a virtual variable. This also helps you to understand from one side that the 64-bit version of the application differs from the traditional 32-bit version of the application. The main content of this column is Visual C + +, not the details of the processor architecture, so I'll just introduce the x86 and x64 processor architecture. Read the documentation in the MSDN library to learn more about the differences that the Itanium processor introduces.

Processor architecture

It is difficult to master the processor architecture in a comprehensive way. This is why C language and its subsequent languages have such a huge impact on the software industry. At a minimum, you should understand what the x86 and x64 processor architectures represent, because they are the type of processors that most users use. Visual C + + and Windows also support Itanium processors, but few developers are willing to target this processor.

In any case, over the past few decades, x86, which has originated in the 8-bit Intel 8080 processor, has dominated the market. AMD and Intel have a realistic choice of x64 to preserve the x86 compatibility. And Itanium introduces a powerful new architecture that is not limited by traditional x86. The result, of course, is that this architecture supports a fairly small number of applications, but this is an empirical example of David Cutler (who led the Windows NT Development) and its portable operating system view that Windows has been able to adopt the new architecture relatively easily over the years.

While the C + + compiler hides many of the differences between processor architectures, developers can clearly see one benefit of this change, namely, a shift to a single calling convention. The x64 version of the C + + compiler supports only a single calling convention, whereas the x86 version of the compiler supports multiple calling conventions. This change is popular because it eliminates multiple potential errors caused by the mismatch of calling conventions, especially in managed code interop. In managed code interop, the Microsoft. NET Framework compiler, such as C # and Visual Basic. NET, cannot determine the original calling convention in the C + + header file. In fact, they must rely on manually defined properties that are easily defined incorrectly, resulting in various stack corruption errors.

For example, before calling a member function, the native C + + calling convention ThisCall use the ECX register to store the "this" pointer. This information is useful for debugging, but depends on the calling convention, which may not be obvious if you are only viewing some assembler code and register values. This is much simpler on x64 because the "this" pointer is always inserted as the first argument and therefore stored in the RCX register.

Of course, the use of registers during debugging is processor-specific, but thankfully we can explore the relationship between x86 and x64. The x86 architecture introduces the concept of a child register, which forms the lower half of the parent register. For example, Ax is a 16-bit child register located in the lower half of the EAX register. The x64 architecture provides a 64-bit register to replace a 32-bit x86 register, which enables register expansion. For example, on x64, the 32-bit EAX registers form the second half of a 64-bit Rax register. Both EAX and Rax have their respective roles, which are used by x86 and x64 to store the pointers or integers returned by the function. There is no doubt that you need to use two registers for functions that run on x86 to return 64-bit values.

Virtual variables

The most common virtual variable may be $err, which displays the previous error value of the function SetLastError setting. The displayed value represents the value that will be returned by the GetLastError function.

Virtual variables can also be used to display the value of a processor register. For example, $ECX display the value of the ECX register for the x86 architecture. For a new generation of developers using. NET, it may be a bit esoteric to see the value of the processor register, but doing so can help diagnose obvious errors or only understand the behavior of the program at run time. If you are using the native C + + calling convention on x86, you can use $ECX to display the address of the "this" pointer. You can also display 32-bit return values using $EAX on two architectures. You can also easily use more registers, depending on your debugging needs.

Other useful virtual variables include $handles and $user, which displays the number of handles to the kernel object that is open in the process, which displays very detailed information about the current process and line begins thread cards. $user can be used to debug code related to impersonation. Figure 1 lists some of the common virtual variables.

Figure 1 Virtual variables

Virtual variables	Description
$handles	Number of handles for kernel objects
$vframe	Current stack frame Address
$TID	Current thread identifier
$registername	Specify the contents of the Register
$clk	Time represented by the clock cycle
$user	Process and line begins thread licensing information