You can refer to this Microsoft Support issue: Working with the AppInit_DLLs registry value
Mentioned in that article, it applies to Win32 Application Interface used with Windows NT 4.0, Windows 2000 Standard Edition and Windows XP. "Note This feature may not be available in future versions of the Windows operating system".
Furthermore, for Windows 8 system, there are desktop mode which use Windows NT kernel and Windows Store Apps mode which use Windows RT kernel.
Windows Store App forbids user to access or modify any register keys.
Why not test an application which uses AppInit_DLLs and works under Windows 7.
If it runs fine in Windows 8 desktop mode, that is to say AppInit_DLLs works for it.
Lazylamb loves smelly cat.
- Marked as answer by Elegentin XieMicrosoft contingent staff, Moderator Tuesday, January 08, 2013 4:26 AM
- Unmarked as answer by pjgaczi Wednesday, February 06, 2013 1:13 PM
My customer is now trying to use an app that has worked for Win XP, Vista and 7.
It does not work for Win 8, even though the usual AppInit_DLLs Registry entries
are present, and I want to know if that failure is by design or is it a "bug" in Win 8 that
may soon be fixed.
Sorry for my delayed response.
I have tried to work with AppInit_DLLs using my own-created sample Win32 Application and DLL. But it is not working in Windows 8 desktop mode. Later I found that in Windows 7, the DLL specific to AppInit_DLLs should be code-signed.
Now I'm trying to involve some senior engineers into this issue and it will take some time. Your patience will be greatly appreciated.
Sorry for any inconvenience.
- Edited by Damon ZhengMicrosoft contingent staff, Moderator Wednesday, December 12, 2012 11:51 AM
Yes, you're right. Refer to this: AppInit_DLLs in Windows 7 and Windows Server 2008 R2 (Windows)
The document says "should be code-signed", "In the interests of application compatibility".
It is not required, just recommended to make code signing for the DLL. I think it is for security sake, because AppInit_DLLs is thought to be an vulnerability that can be modified by malwares.
- Edited by Damon ZhengMicrosoft contingent staff, Moderator Wednesday, December 12, 2012 12:21 PM
Did you write to the 32 bit registry?
On 64 bit Windows, it is located under the following registry key:
I saw AppInit_Dll being used on my 64 bit Windows 8 system.
I would like to mention that you should try to avoid using this technique as it may go away in the future. We mention this in the following link (It would apply to Windows 8 as well):
Appinit based DLL injections are disabled when (UEFI) Secure Boot is enabled.
You can easily verify the Secure Boot State on your customer machine using msinfo32.
FYI, Usage of AppInit DLLs is considered a Windows logo failure, for Windows 8 desktop apps.
- Proposed as answer by itaish Wednesday, December 18, 2013 9:22 AM
Is it correct to say that both AppInit_DLLs and SetWindowsHookEx() are
disabled if Secure Boot is enabled for Win8?
I've been using AppInit_DLLs for DLL injection into limited processes
for my product for years. Is there a new accepted way to do DLL injection?
Is there a programmatic way to tell if Secure Boot is not just present,
but enabled as well?
Is there a way to keep AppInit_DLLs without disabling the rest of
Can you give us some information on why Secure Boot, which is by its name a boot-time feature, is affecting user session-time behaviour, ie Appinit?
I have not found any documents refering to this behaviour, can you point us to any info you have on this?
I totally agree with your argument about Secure Boot being a boot-time feature (not only by name but also by spec ) and not related to Appinit.
Furthermore, according to Steven Sinofsky post, in the Building Windows 8 blog, “Secure boot is a UEFI protocol not a Windows 8 feature”.
As for the “why?” I really don’t know. Official answer I got from a Microsoft escalation engineer was somewhat ambiguous “The design change has been taken based on several factors primarily being security.”
Currently I am not aware of any official documentation referring to this behavior.
I am getting more complaints from my customers about the disabling
of AppInit_DLLs for UEFI and Secure Boot.
I know that Citrix, Google Desktop, and Kaspersky Anti-Virus have been
using AppInit_DLLs. What alternative did they employ for DLL injection?
I read that msinfo32.exe can detect the Secure Boot State: is there a way
to do this programmatically in C++?
Is there a way to disable the effect of Secure Boot on AppInit_DLLs
Is there a new accepted way to do DLL injection?
Please ask your "Microsoft escalation engineer" friend or someone else at MSFT
to contact me with answers. Click "Email Us" at www.gaczi.com.
My guess is that the only programmers who are going to be thwarted by
Secure Boot are the honest ones. A Google search for "disable Secure Boot"
shows that this is controversial "improvement".
If by “Did you get solution this problem?” you are referring to the thread’s main question “Does AppInit_DLLs still work for 32-bit apps on 64-bit Windows 8?” I’d say my post IS the thread answer.
e.g. Yes AppInit_DLLs still work for 32-bit apps on 64-bit Windows 8 unless it is a secure boot (UEFI) which disables AppInit_DLLs.
And if you are referring by “this problem” to the question I raised “why did Microsoft decided to disable the AppInit_DLLs mechanism on UEFI secure boot” I’d say no.
However, this behavior has been since documented.