Assembly Language Programming: Code Conversion

int *ptr = new int;
if(ptr) may generate "test eax eax" . Test instruction tests against zero

Reference:
X86 Disassembly/Optimization Examples

LoadLibrary

When we do loadLibary for some dll then while loading the library, loadlibray calls the loader lock function which locks the loader.

ntdll!ZwWaitForSingleObject+0x15 (FPO: [3,0,0])
ntdll!RtlpWaitOnCriticalSection+0x1a3 (FPO: [2,7,4])
ntdll!RtlEnterCriticalSection+0xa8 (FPO: [1,1,0])
ntdll!LdrLockLoaderLock+0xe4 (FPO: [SEH])
ntdll!LdrLoadDll+0xc9 (FPO: [SEH])
kernel32!LoadLibraryExW+0x1b2 (FPO: [SEH])
kernel32!LoadLibraryW+0x11 (FPO: [1,0,0])

This helps in proper initialization of library.

ULONG64 on 32 bit machine

unsigned __int64 var64 = 100;

How to access lower and higher order DWORD in var64?

We can use below mentioned structure.

typedef union _ULARGE_INTEGER {
struct {
DWORD LowPart;
DWORD HighPart;
};
struct {
DWORD LowPart;
DWORD HighPart;
} u;
ULONGLONG QuadPart;
} ULARGE_INTEGER;

ULARGE_INTEGER largeVar = 0;

largeVar.QuadPart = var64;

Now you can access.
DWORD LowPart = largeVar.LowPart;
DWORD HighPart = largeVar.HighPart;

These structure can be found at WinNT.h

How LONG64 is stored on stack?

First higher order DWORD is pushed and then lower order DWORD.

code snippet:

unsigned __int64 var = 10;
ULARGE_INTEGER value;
value.QuadPart = var;
value.LowPart = 60;
value.HighPart = 70;


unsigned __int64 var = 10;
00031036 mov dword ptr [var],0Ah
0003103D mov dword ptr [ebp-0Ch],0
ULARGE_INTEGER value;
value.QuadPart = var;
00031044 mov eax,dword ptr [var]
00031047 mov dword ptr [value],eax
0003104A mov ecx,dword ptr [ebp-0Ch]
0003104D mov dword ptr [ebp-4],ecx
value.LowPart = 60;
00031050 mov dword ptr [value],3Ch
value.HighPart = 70;
00031057 mov dword ptr [ebp-4],46h


stack view

0x0019FCEC 0000000a //lower local param1
0x0019FCF0 00000000 //higher local param1
0x0019FCF4 0000003c //lower local param2
0x0019FCF8 00000046 // higher local param2
0x0019FCFC 0019fd40 // ebp

Good Links

A Crash Course on the Depths of Win32™ Structured Exception Handling

Exception Handling

First and second chance exception handling

Distinction between the first and second chance exception: the debugger gets the first chance to see the exception (hence the name). If the debugger allows the program execution to continue and does not handle the exception, the program will see the exception as usual. If the program does not handle the exception, the debugger gets a second chance to see the exception. In this latter case, the program normally would crash if the debugger were not present.

If you do not want to see the first chance exception in the debugger, you should disable first chance exception handling for the specific exception code. Otherwise, when the first chance exception occurs, you may need to instruct the debugger to pass on the exception to the program to be handled as usual.

Does a first chance exception mean there is a problem in my code?
First chance exception messages most often do not mean there is a problem in the code. For applications / components which handle exceptions gracefully, first chance exception messages let the developer know that an exceptional situation was encountered and was handled.


References:
First and second chance exception handling