Rare 0xc0000018 error on w81 64b apps

c++ / delphi package - dll injection and api hooking

Re: Rare 0xc0000018 error on w81 64b apps

Postby Overnissen » Fri Mar 11, 2016 5:35 pm

So, I downloaded the madCodehookBeta, extracted the .sys drivers, reconfigured and signed them.

That seems to do the trick, so now the applications where the .dll is injected into do no longer give the 0x0000018 error, so that's a good thing.. ;)

However, I have experienced that some applications (such as Firefox and Photoshop) suddenly starts to use 100% cpu on the processor core they are running on and the explorer shell stops responding repeatedly (this is on Win7), the hooking .dlls are the same as before and they worked like a charm with the "old" .sys drivers.

There may be something I'm not doing in the hooking .dlls that the "old" (current release) drivers somehow are not susceptible to - like, I don't think I ever specifically call "InitializeMadCodeHook" for example..

Anybody else experienced something similar..?
Overnissen
 
Posts: 28
Joined: Mon Dec 29, 2014 6:22 pm

Re: Rare 0xc0000018 error on w81 64b apps

Postby madshi » Fri Mar 11, 2016 5:59 pm

No such problems here. Which OS version and bitdepth are we talking about? And which development system are you using? Did you just change the drivers or did you also recompile the hook dlls with the new version (you don't have to, but I need to know)?
madshi
Site Admin
 
Posts: 9147
Joined: Sun Mar 21, 2004 5:25 pm

Re: Rare 0xc0000018 error on w81 64b apps

Postby Overnissen » Fri Mar 11, 2016 8:41 pm

No, I only re-configured the Beta drivers, I did not recompile using the beta codeHook code.

I'm running it on Win7 x64 and using Delphi XE5.
Overnissen
 
Posts: 28
Joined: Mon Dec 29, 2014 6:22 pm

Re: Rare 0xc0000018 error on w81 64b apps

Postby madshi » Fri Mar 11, 2016 9:06 pm

Can you update to the latest beta build once more, just to make sure you're using the very latest one? I've updated the beta build serveral times in the last couple of days. The latest build right now is:

http://madshi.net/madCollectionBeta.exe (installer version 2.7.12.11)

Please only update the drivers, keep the rest as it is. If you still have those freezes, could you check if you can reproduce the problem with one of the demos? E.g. try this one:

http://madshi.net/PrintMonitor.zip

Try creating new drivers for this demo, too, based on the beta build. Keep the other demo files (exes+dlls) unchanged. Does this demo then show the same freezes on your PC? If it does, the problem is definitely in the driver. If not, it might be something else.

Thanks!

P.S: InitializeMadCHook() is only for MSVC++ users.
madshi
Site Admin
 
Posts: 9147
Joined: Sun Mar 21, 2004 5:25 pm

Re: Rare 0xc0000018 error on w81 64b apps

Postby Overnissen » Sat Mar 12, 2016 4:41 pm

Hey madshi,

A quick update.

I updated the drives using the latest Beta drivers, but there's no change, it still does it.

I then took the PrintMonitor demo and replaced renameme32+64.sys with those from the Beta Package, signed .dlls, configured drivers and signed drivers, no problem when that is running, so I'm a bit at a loss.

Why I was thinking it to be the drivers in the first place, is because my widget works perfect on Win7 with the release drivers, on Win7 that is, but replacing them with the new drivers everything spaces out, so I kind thought it to be the drivers.

I'll be adding some IPC debug messaging to the drivers, that might give me a clue to what's happening, so "I'll be back" (with a thick Austrian accent :).

Thank you so far :)
Overnissen
 
Posts: 28
Joined: Mon Dec 29, 2014 6:22 pm

Re: Rare 0xc0000018 error on w81 64b apps

Postby madshi » Sat Mar 12, 2016 5:04 pm

Hehe, just watched Terminator Genisys yesterday... :D

I've no clue why a different injection driver should make your hook dll misbehave. Makes no sense to me. Have you tried commenting out the HookAPI() calls, just as a test?

Does your hook dll do anything fancy in DllMain (or during unit initialization)? E.g. are you loading further dlls? Or are you creating threads?
madshi
Site Admin
 
Posts: 9147
Joined: Sun Mar 21, 2004 5:25 pm

Re: Rare 0xc0000018 error on w81 64b apps

Postby Overnissen » Sat Mar 12, 2016 8:25 pm

I guess my reference was very well placed :D

Quite frankly, I don't know if it's the hook .dll that's misbehaving par se, I can only observe that certain processes starts to misbehave and nothing have been changed but the injection driver, so it was kinda natural to me to suspect that it was something with the driver, not that I know for sure that it's the driver as such..

My hook .dll is not loading any other .dlls and it creates no threads, not so sure about the fancy part.

The hook .dll hooks all the LoadLibrary calls and then proceed to hook all the dns resolution apis in the various winsock .dlls (getaddrinfo, DNSQuery_W and so on) as well as the connect and sendto calls.

Why it hooks loadlibrary is if the winsock .dlls are not loaded at the point of injection, then I want to hook them as (if) they get loaded later.

Currently I'm inserting some debug messaging code to signal what gets called and when, that way it might give me some kind of idea of where it may be looping, if that's the case (I don't thinks so, but you never know).

I have been thinking that by me hooking the loadlibrary calls during dllmain it might overwrite a return pointer or something, but time might tell.. ;)
Overnissen
 
Posts: 28
Joined: Mon Dec 29, 2014 6:22 pm

Re: Rare 0xc0000018 error on w81 64b apps

Postby madshi » Sat Mar 12, 2016 8:33 pm

The reason why I thought that maybe the injection driver might make your hook dll misbehave is that you weren't able to reproduce the problem with the PrintMonitor demo. That makes me think that the DLL injection itself seems to work ok, and that's really all the driver does! So this is a bit of a mystery to me. I've no idea what's going on. Simply makes no sense to me. If you had recompiled the hook DLLs, too, then it suddenly would make sense. But only changing the driver causing problems is really weird, especially if the PrintMonitor demo doesn't show the same problem.

FYI, you can delete all your LoadLibrary hooks etc. Simply call HookAPI() in DllMain. madCodeHook has all the LoadLibrary hooking stuff etc automated internally for you. It did that from day 1. HookAPI() will succeed even if the hook dll you want to hook isn't loaded yet. Then when it's loaded, madCodeHook will automatically install the API hooks for you. When later, when the target DLL gets unloaded and reloaded, again madCodeHook will take care of everything for you. But it might make sense to delay doing this change until we've figured out the problem with the driver.
madshi
Site Admin
 
Posts: 9147
Joined: Sun Mar 21, 2004 5:25 pm

Re: Rare 0xc0000018 error on w81 64b apps

Postby Overnissen » Sat Mar 12, 2016 10:54 pm

Well now, that was a nice feature hooking the LoadLibrary calls, I was not at all aware of that..

I don't know it that's the culprit, but I might mess things up doing just that..

Most of the rest of the hooking .dll is based on code that I have already tested over a long period and have already been released, but now that you mention it, the misbehaving might have started after I implemented the LoadLibrary hooking, even though it appeared to work when I ran it in the debugger, but to be honest I really can't remember exactly.

The hooking .dll shows some signs of randomly causing the problem and not, when injected stand-alone, so I'll try and remove the LoadLibrary hooks and see if it changes the behavior.. ;)
Overnissen
 
Posts: 28
Joined: Mon Dec 29, 2014 6:22 pm

Re: Rare 0xc0000018 error on w81 64b apps

Postby Overnissen » Sun Mar 13, 2016 12:24 am

Okay..

I commented out all the LoadLibrary hooks and the problem appears to be gone.

I'm thinking that what I have been seeing might be some kind of race condition, where my code is hooking LoadLibrary and when the libraries I "subscribed" to by calling HookAPI() on .dlls that was not loaded gets loaded, I first hook them and then madCodeHook tries to hook them again behind the scenes, maybe..

After knowing what to look for, I could see that the CPU usage in the process increased as libraries got loaded, so if the usage was at say 65% and somewhat steady there, when another .dll was loaded by the process (Chrome in this case), the CPU usage bumped up a notch higher, this continued until it hit 99% CPU usage and then the application seems to grind to a halt..

My apologies I suspected the driver first, but it really looked like it worked without any problems with the release driver, but that have to be coincidental - which is a thing that sucks with intermittent bugs..
Overnissen
 
Posts: 28
Joined: Mon Dec 29, 2014 6:22 pm

Re: Rare 0xc0000018 error on w81 64b apps

Postby iconic » Sun Mar 13, 2016 7:44 am

Overnissen,

Not sure what you're doing within your LoadLibrary hook but perhaps you could avoid this entirely and look at LdrRegisterDllNotification(). It's available on Vista+ and will provide the DLL base, image size etc. before the module's entry point is actually called.

--Iconic
iconic
 
Posts: 777
Joined: Wed Jun 08, 2005 5:08 am

Re: Rare 0xc0000018 error on w81 64b apps

Postby madshi » Sun Mar 13, 2016 8:20 am

@Overnissen, if it's some sort of race condition, maybe you can try reproducing the problem with the old drivers, too? Maybe it occurs with them, too (but maybe less often)? If so, that would prove that the problem is not in the drivers? That would give us piece of mind. Generally, though, I don't think there should be a conflict between the two of us trying to hook LoadLibrary. So I'm not sure where the problem comes from. But then, as I mentioned before, what you're doing is really not necessary, so if removing that fixes all problems, maybe we should stop investigating there. However, maybe you did stumble over some weird driver bug. So getting some piece of mind would be great!

@iconic, he didn't know that madCodeHook already takes care of hooking newly loaded dlls automatically, so he duplicated this logic in his hook dll, which was kinda superfluous. Btw, LdrRegisterDllNotification() is nice, but it seems to be very sensitive. I'm currently investigating some issues which occur when using it in madCodeHook instead of my own LoadLibrary hooks, and I might have to remove LdrRegisterDllNotification() again. Doing things in the LdrRegisterDllNotification() callback seems to be *more* sensitive than doing things in DllMain.
madshi
Site Admin
 
Posts: 9147
Joined: Sun Mar 21, 2004 5:25 pm

Re: Rare 0xc0000018 error on w81 64b apps

Postby iconic » Sun Mar 13, 2016 8:49 am

he didn't know that madCodeHook already takes care of hooking newly loaded dlls automatically, so he duplicated this logic in his hook dll, which was kinda superfluous


I see :D

Btw, LdrRegisterDllNotification() is nice, but it seems to be very sensitive.


I've used the API since (2006/2007?) when I first discovered it was exported on Vista in my own private hooking engine and also use it to prevent DLL injection into my own process (overwriting the entry point to prevent loading). IE 10's enhanced protected mode also uses it as well (actually, the shim engine does this directly). It's tried and proven and a better solution as opposed to hooking LoadLibrary variants, which causes a lot of problems as you already know, maybe it's why you hook deeper into the LL functions or at least used to? The only thing I have noticed is that some API calls will fail when used inside the ldr callback, so yes in this sense it is "sensitive" as you have mentioned. If you stick to NT APIs (especially Ldr* APIs) I think it can be worked around ;)

--Iconic
iconic
 
Posts: 777
Joined: Wed Jun 08, 2005 5:08 am

Re: Rare 0xc0000018 error on w81 64b apps

Postby madshi » Sun Mar 13, 2016 9:42 am

It's a "nicer" solution, I'm not convinced yet about "better". If some APIs fail when called inside of the callback that already suggests that it might have some new problems of its own. If IE uses it in its own process, and if you use it in your own process, that's a MUCH smaller area than all my customers using it on all processes of all machines of all their users. madCodeHook simply has a very high requirement for stability because it must work very stably inside of virtually every process in the world.

That said, I would *love* to use an official API instead of using hooking. But I can do that only if the API is at least as stable as my own hooking. Which so far doesn't appear to be the case. But I'm still investigating issues reported by two different users who've tried the new API based solution, so I don't have a final opinion about this yet. But there's already a strong indication: The new API based solution was only out in beta form, but still two different users already reported problems, while nobody seems to have any problems with my older hooking based solution. No good sign for stability of the API based solution. Could be a bug in my code, of course, we'll see.
madshi
Site Admin
 
Posts: 9147
Joined: Sun Mar 21, 2004 5:25 pm

Re: Rare 0xc0000018 error on w81 64b apps

Postby iconic » Sun Mar 13, 2016 10:12 am

Completely understand and agree with you 100%. I guess it just depends on what you're doing (or not doing?) inside the ldr callback, remember that this happens pretty early in the dynamic linking phase, so any "strange" behavior or quirk is likely due to this reason of the callback being called so early on. I meant it's a "better" method in the context of it being a hook-free solution and an "official API" as you've elegantly put it. Hopefully you'll be able to determine with conviction what any issues are in the beta, best of luck! :D

--Iconic
iconic
 
Posts: 777
Joined: Wed Jun 08, 2005 5:08 am

PreviousNext

Return to madCodeHook

Who is online

Users browsing this forum: No registered users and 2 guests