0xC0000022 before RtlUserThreadStart

Question

I'm injecting some code to hook apis in processes but I have some issues in some applications like chrome.exe

My test app launches a suspended process, do injection and api hooking and then resumes it.

CreateProcessW is hooked in order to be able to hook child processes. If CreateProcessW is called, it is forced to be created suspended, hook the child and resume it.

The injected code only depends on ntdll api's so, although hooked processes are not fully initialized yet, ntdll.dll is always present.

Code is injected using a helper thread using CreateRemoteThread or NtCreateThreadEx with the CREATE_SUSPENDED flag. (No matter which one, the issue still there)

After this intro, the problem is that in some processes like some chrome childs, CreateRemoteThread returns TRUE but when I resume the injector thread, it exits with code 0xC0000022 and the process exits too.

If I attach WinDbg to a chrome.exe child process that is suspended, before I do anything, it fails too and chrome.exe ends with the same behavior.

Seems O.S. code executed before RtlUserThreadStart, generates the error but I don't know how to debug it.

How can I debug code that runs before RtlUserThreadStart? Is there a debugger or a windbg option that allows me to do that?

EDIT:

Following the last post from here, I could retrieve this info:

0a88:0814 @ 02688302 - LdrpInitializeProcess - INFO: Beginning execution of chrome.exe (c:\Program Files (x86)\Google\Chrome\Application\chrome.exe)
    Current directory: C:\Windows
    Search path: C:\Windows\SYSTEM32 0a88:0814 @ 02688318 - LdrpInitializeProcess - ERROR: Initializing the current directory to "C:\Windows" failed with status 0xc0000022
0a88:0814 @ 02688334 - LdrLoadDll - ENTER: DLL name: C:\Windows\SYSTEM32\wow64.dll DLL path: NULL 0a88:0814 @ 02688349 - LdrpLoadDll - ENTER: DLL name: C:\Windows\SYSTEM32\wow64.dll DLL path: C:\Windows\SYSTEM32
0a88:0814 @ 02688365 - LdrpLoadDll - INFO: Loading DLL C:\Windows\SYSTEM32\wow64.dll from path C:\Windows\SYSTEM32 0a88:0814 @ 02688380 - LdrpFindOrMapDll - ENTER: DLL name: C:\Windows\SYSTEM32\wow64.dll DLL path: C:\Windows\SYSTEM32
0a88:0814 @ 02688396 - LdrpSearchPath - ENTER: DLL name: C:\Windows\SYSTEM32\wow64.dll DLL path: C:\Windows\SYSTEM32
0a88:0814 @ 02688412 - LdrpResolveFileName - ENTER: DLL name: C:\Windows\SYSTEM32\wow64.dll
0a88:0814 @ 02688427 - LdrpResolveFileName - RETURN: Status: 0xc0000022
0a88:0814 @ 02688443 - LdrpSearchPath - RETURN: Status: 0xc0000022
0a88:0814 @ 02688458 - LdrpFindOrMapDll - RETURN: Status: 0xc0000022
0a88:0814 @ 02688474 - LdrpLoadDll - RETURN: Status: 0xc0000022
0a88:0814 @ 02688490 - LdrLoadDll - RETURN: Status: 0xc0000022
0a88:0814 @ 02688505 - LdrpInitializeProcess - ERROR: Loading WOW64 image management DLL "C:\Windows\SYSTEM32\wow64.dll" failed with status 0xc0000022
0a88:0814 @ 02688521 - _LdrpInitialize - ERROR: Process initialization failed with status 0xc0000022
0a88:0814 @ 02688536 - LdrpInitializationFailure - ERROR: Process initialization failed with status 0xc0000022

The process is created with a restricted token, the main thread inherits it but my injector thread isn't restricted because it is created by my app.

I can assume ntdll's apis are not hooked yet by chrome (in this case) because injection takes place before CreateProcess returns to chrome.

May the non-restricted token in my thread conflicts with process token in some way?

Answer 1

Take a look at Debugging WinLogon in the windbg help (debugger.chm). Simply substitute "chrome.exe" for "winlogon.exe". This technique controls a user mode debugger (ntsd) from the kernel mode debugger. I believe this will allow you debug chrome.exe's process initialization much earlier than using a user mode debugger alone.

Answer 2

The issue in chrome was the following:

Chrome launches child processes with very limited privileges (because of the sandbox) but before resuming the main thread it impersonates the main thread with a token with more privileges in order to let the process initialize.

My injector thread was not impersonating so the limited process token raised the 0xC0000022 exit code when the LdrpInitializeProcess routine was executed.