painful debugging due to forget to cancel asynchronous IO operations

Under windows, you can issue asynchronous IO operations to the kernel. sometimes, you are impatient  to wait for the completion of the operation. Then you need to use CancelIoEx() to cancel this operation.

My recent code does not cancel the operation and I simply free the hEvent associated with the asynchronous IO operation. The consequence is extremely severe. The stack of my program has been tampered. I experienced STATUS_STACK_BUFFER_OVERRUN error.

It was a futile effort and I spent lots of time understand the STATUS_STACK_BUFFER_OVERRUN error and lots of time examine the assembly code. Then I found out the code stack has been modified by someone else. Then I began to re-check the entire code logic and finally caught the culprit.

re-enable classic start menu on windows server 8

I am not a big fan for the metro-style UI on windows 8, especially on windows server 8. Therefore the very first thing after I installed a windows 8 server. I try to turn off the metro-style UI and get the classic start menu back. Here is how:

In regedit,

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer

change value of RPEnabled from "1" to "0"

Calling conventions of VC

VC has three calling conventions

• /Gd, the default setting, specifies the __cdecl calling convention for all functions except C++ member functions and functions marked __stdcall or __fastcall.
• /Gr specifies the __fastcall calling convention for all functions except C++ member sfunctions and functions marked __cdecl or __stdcall. All __fastcall functions must have prototypes.
• /Gz specifies the __stdcall calling convention for all functions except C++ member functions and functions marked __cdecl or __fastcall. All __stdcall functions must have prototypes.

Decorated Names for different calling conventions:

• For C, the __cdecl naming convention uses the function name preceded by an underscore ( _ ).  Generally the function arguments are passed on the stack in reverse order so that the callee can access them in the correct order. The caller is responsible for popping the arguments after the function returns, which makes it possible to use the ... to send runtime defined arguments. Return values are returned in the registers.
   _functionname
• For C, the __fastcall naming convention uses the function name preceded by an at sign (@) followed by the size of the function's arguments in bytes. Some of a __fastcall function's arguments are passed in registers (for x86 processors, ECX and EDX), and the rest are pushed onto the stack from right to left. The called routine pops these arguments from the stack before it returns. @function_name@number
• For C, the __stdcall naming convention uses the function name preceded by an underscore ( _ ) and followed by an at sign (@) and the size of the function's arguments in bytes. A __stdcall function's arguments are pushed onto the stack from right to left, and the called function pops these arguments from the stack before it returns. _functionname@number

Calling Conventions supported by VC