madshi.net

Flags in HookAPI are always ZERO. The only thing he is not using right is that he has -unsafeStopAllowed flag in driver configuration. Is it a factor in this case? He will restart and check it with -safeStopAllowed soon.

Find all "NO_SAFE_UNHOOKING", Subfolders, Find Results 1, "Entire Solution"
Matching lines: 0 Matching files: 0 Total files searched: 3371

No.

Yes, I understand that during process termination we can safely leave memory leaks there (just to be sure). But this bug (crashing app) is happening during DLL uninjection and not during process termination. Am I missing something?

Hi, as a result of our last discussion http://forum.madshi.net/viewtopic.php?f=7&t=27415 we don't use manual unhooking inside DLL detach anymore. Sadly, we have encountered another issue during runtime DLL uninjection (UninjectAllLibrariesW). Take a look at attached screenshot. You can see that ...

I see, it is fine then. Thx for info.

Yes, we do call FinalizeMadCHook() in Dll detach call. Isn't it a problem to let the FinalizeMadCHook to unhook everything without waiting? If i understand it correctly this could cause a problem. For example, CloseHandle hook + rogue threads calling CloseHandle at the same time we call FinalizeMadC...

I disabled manual Unhooking and it seems to do the trick. My co-worker is back and I asked him why he used manual unhooking. He claims, that without it, some apps crash somewhere else. So I am cautious about disabling that manual unhooking for all hooks. I will disable manual NtDeviceIoControlFile U...

1) Yes, we are manually calling hook inside Dll attach and unhook inside Dll detach. Is that a problem?
2) Well you might be right, main thread is not rock solid way to do that. But I think that in case of TerminateProcess, DllMain detach is not called at all. That code sample was merely an idea.

You can identify "main thread" by comparing thread start times in every app you want...

Notepad is definitely not our own .exe.

4) I put breakpoint inside that thread. 5.png 5) I let notepad to continue, hoping to get hit by breakpoint inside that work thread. After a while I use "break all" command. Workthread no longer running. Madhook cycling forever inside ~CCodeHook(). 6.png 6) If I check counter inside that h...

I hope I understand it correctly: If app is terminating itself (DllMain is called from main app thread), I can then just leave NtDeviceIoControlFile hook active and let the DLL unload? Well, that is possible, but I think it is not quite right. I mean this is special case. I don't frankly understand ...

I have inspected "NO_SAFE_UNHOOKING" flag, and it is not a solution for us, since we want to have the best system stability possible. This could cause some problems with processes not related to this kind of issue. I have a few possible workarounds in my mind right now. But all of them are...

OK, thx. We will try that.

Hi, I have a problem with unhooking NtDeviceIoControlFile. The problem is a deadlock inside ~CCodeHook(). Problem with this (source code excerpt from madhook added) is that it is not taking into account thread termination. The best way to reproduce this issue is to hook NtDeviceIoControlFile in Note...