I'm trying to implement out-of-process crash handling for my shipped application - as in-process reporting is not reliable enough, and will result in me not getting any information on certain crashes.
I implemented the required callbacks for a custom WER DLL, and register it using WerRegisterRuntimeExceptionModule. The whole process generally works, but there is a problem in with the part of registering the DLL in the windows-registry. It works only if I register my DLL in the location under HKEY_LOCAL_MACHINE. According to MSDN, it should also be possible to put the RuntimeExceptionHelperModules-entry under HKEY_CURRENT_USER. However, the WER-DLL will not be executed if the entry is in HKEY_CURRENT_USER - only if it is inside HKEY_LOCAL_MACHINE.
This is a problem, as my application right now does not have an installer, and I do not require any administrative privileges in general, so I do not as the user to start the app with elevated privileges. However, for writing into HKEY_LOCAL_MACHINE, this would be required. I would really prefer to not have to ask for privileges, especially not all the time - I'd have to make a separate .exe if I wanted to ask only once.
I've checked that the path itself is correct, and at the correct location - I even have other applications registered there. It's irrelevant if I do it programmatically or by hand - if I copy the same key from HKEY_CURRENT_USER to HKEY_LOCAL_MACHINE, it works. Since WerRegisterRuntimeExceptionModule is also trivial and doesn't have any configuration arguments, I don't think there is much point in showing it. Return-values is obviously S_OK - the function doesn't give you any idea if somethings going wrong. I need to test this on users machines to see if maybe something is locally configured wrong on my dev-machine, but that'll take a while.
So, in the meanwhile, just in a general sense, is there any reason why WER would only accept a DLL that is registered under HKEY_LOCAL_MACHINE, but not HKEY_CURRENT_USER? If there is, is there some way to control it that doesn't require UAC-access on the clients machine (in which case I could just write it to HKEY_LOCAL_MACHINE instead). Or is HKEY_CURRENT_USER simply not possible to register your DLL, despite that it appears to be?
Unfortunately I couldn't find any documentation to back this claim, but registering the WER handler in HKCU is only supported since Windows 10 2004. Also, note that handlers registered in HKCU are notified of the crash (OutOfProcessExceptionEventCallback will be called) but they can't claim ownership (so OutOfProcessExceptionEventSignatureCallback and OutOfProcessExceptionEventDebuggerLaunchCallback won't be called).