Code corruption of dll on using LoadLibrary - Windows 7 32Bit only.


  • I'm having a very strange problem that occurs only under Windows 7 (32 or 64) whilst loading a 32bit dll into a 32bit host application.

    A quick background to what I'm doing:
    I am using a #pragma code_seg(...)  to create a special code segment to hold sensitive functions that I then encrypt with a separate program using the windows crypto API (CryptEncrypt etx from WinCrypt.h). When the dll is loaded I have a function that locates this code segment in memory and decrypts it so that the sensitive functions can then be called as normal.

    This all works fine under all OS's apart from Windows7 (32 or 64) when the dll and host application are 32bit - using a 64bit host and dll on Windows 7 64 though is fine.

    What appears to be happening is that when the dll is loaded, a few bytes present in the special code segment area of memory are corrupted within the loadlibrary call - just the odd pair of bytes here and there - but this obviously causes a crash. If I compare a hex view of the dll and the memory where the dll is loaded, I can see these altered bytes (ie, the dll holds the correct code and it is upon loading that it gets altered).

    It's very, very odd, and i cannot explain it. Could anyone shed any light on what LoadLibrary might be doing under Win7, and how i might get around it. Just to note, the dll does not have to relocate for this to happen. It happens 100% of the time on more than one test machine. I can also reproduce outside of my app within a simple test harness.

    Here is the beginning of the segment as seen in the dll (first line) and after loadlibrary in memory (second line). Note the 2 bytes second and third from the end - they are different.

    9a 65 b5 63 72 3f fb 5f 06 74 c5 cf 4a 64 38 7f 34 8e c5 e6 63 d2 2b b4 5e 24 63 fe e3 67 8f 7d
    9a 65 b5 63 72 3f fb 5f 06 74 c5 cf 4a 64 38 7f 34 8e cb 4a 63 d2 2b b4 5e 24 63 fe e3 6d f3 7d

    Thanks in advance for any help,


    Sunday, July 18, 2010 7:48 AM