9

The game Red Alert 2 runs on Windows 8, but as soon as I inject a DLL (via ddraw.dll or an extra DLL) it stops drawing buttons on the main menu. With the DLL it still work fine in windowed mode and it still works fine on Windows 7. The DLL is basically just

typedef HRESULT(WINAPI* LPDIRECTDRAWCREATE)(GUID*, LPDIRECTDRAW*, IUnknown*);
HMODULE dd_dll = LoadLibrary("system32/ddraw.dll");
LPDIRECTDRAWCREATE dd_create = reinterpret_cast<LPDIRECTDRAWCREATE>(GetProcAddress(dd_dll, "DirectDrawCreate"));
return dd_create(lpGUID, lplpDD, pUnkOuter);

I'm guessing some kind of automatic compatibility mode is activated for the original game that gets disabled by the DLL, but how do I find out what's causing this? It's important as the DLL provides improvements for gamers that should also be available on Windows 8 (and beyond).

8
  • 1
    Do you always inject the same DLL? Does the same thing happen if you inject a completely different DLL?
    – DCoder
    Sep 21, 2014 at 5:20
  • Possibly system32/ddraw.dll is different location on windows 8? it might be the way you inject the dll that causes this problem.
    – SSpoke
    Sep 22, 2014 at 2:58
  • 1
    It also might be the way you inject the dll that causes this problem. I found when injecting dll files its always best to set debug privileges with AdjustTokenPrivileges before using OpenProcess. Also sometimes allocating the dll into heap of target doesn't work at all because WriteProcessMemory is protected but then again just allocating path of the dll works just fine. Also in the end try using CreateRemoteThread method. Check to see if your hooked kernel32.dll LoadLibraryA actually works right when it Loads your dll file.
    – SSpoke
    Sep 22, 2014 at 3:07
  • 1
    Perhaps use another method to inject your DLL that does not require DLL Hijacking? Also, executing the direct draw code in your DLL's main function could also cause troubles. perhaps create a thread and do that there?
    – NirIzr
    Aug 16, 2016 at 11:26
  • 1
    If a shim is used for the game to work properly, it stands to reason that some other version of said DLL from SxS is picked or that some patching happens unbeknownst to you. There are tools to investigate the shims applied and this should give you a clue where to look ...
    – 0xC0000022L
    Jun 15, 2018 at 19:05

1 Answer 1

1
  1. The easiest way to see if a compatibility SHIM is applied, is to examine the Process Environment Block (PEB) of the process and check __COMPAT_LAYER environment variable if it is set. If it's set it will have space delimited name of SHIMs applied. You can do this with a tool such as Process Explorer, Process Hacker right clicking the EXE when running, selecting Properties and checking Environment tab. You can also find this with WinDbg with !peb command when attached to the process.

  2. You can view the compatibility database as well as create/test your own SHIM settings with the Application Compatibility Toolkit, which is part of the Windows ADK Using Compatibility Administrator you can view/create SHIMs. This tool is located at "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Application Compatibility Toolkit\Compatibility Administrator (32-bit)\Compatadmin.exe" for 32-bit processes and "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Application Compatibility Toolkit\Compatibility Administrator (64-bit)\Compatadmin.exe" for 64-bit processes.

  1. You can automatically query the app compat database yourself via the APIs referenced in Microsoft's Application Compatibility Database Developer Notes or use this open source app Sdb2Xml If you find in the first step you are having SHIMs applied then this query in the database will help you identify why. The databases are located in C:\Windows\apppatch and C:\Windows\apppatch\CustomSDB and have SDB file extension. If you can rename the EXE or change the version info on the EXE so it doesn't match in the database will stop it from getting the SHIM. You can also try hooking at lower level APIs (sometimes undocumented) to ensure you are not overwritten by SHIMs, although this needs a low level understanding.

  2. This may not work depending on the applications anti-debugging techniques, but I have been able to work out complicated hooking issues using the Time Travel Debugging feature of WinDbg

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.