RogueKiller blocks on ProcessTree

[Tigzy]

EDIT 02/18/2014. This is not fixed. We still need debug informations please.


Hello
This is a known issue, but we are unable to fix it due to lack of information.
If you have this problem, please follow the instructions below in order to help us fixing this issue. 

- Download the debug version: http://www.sur-la-toile.com/RogueKiller/RogueKiller_DEBUG.exe
- Launch it.
- When it blocks, go to : %Desktop%/RK_Quarantine folder and copy the debug.log file on the desktop.
- It can be huge, so please remove all but the last 100 lines with a text editor like notepad. Save it.
- In this thread, attach this tiny report and please provide your OS information with it (Windows XP, Windows 7 64 bits/32 bits, ... )

Thanks in advance

[thisisu]

Hi Tigzy,

Windows 7 Home Premium SP1 x64

Last 30 lines attached.

Note: It doesn't always hang. I had to launch the debug version about 6 times for it to finally hang again.

__

ProcessExplorer created a blank 0 byte .dmp file. No information to report from it.

Maybe this will help though? Stack information on RogueKiller_DEBUG.exe+0x1ea980

Code: [Select]

ntoskrnl.exe!KeWaitForMultipleObjects+0xc0a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x732
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!PoStartNextPowerIrp+0xba4
ntoskrnl.exe!PoStartNextPowerIrp+0x1821
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x93d
ntoskrnl.exe!KeWaitForMutexObject+0x19f
win32k.sys!memset+0x7a47
win32k.sys!memset+0x7ae9
win32k.sys!memset+0x612c
win32k.sys!memset+0x6235
win32k.sys!memset+0x7c11
ntoskrnl.exe!KeSynchronizeExecution+0x3a23
wow64win.dll+0x3fe3a
wow64win.dll+0x1aea8
wow64.dll!Wow64SystemServiceEx+0xd7
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42b
ntdll.dll!RtlUniform+0x6e6
ntdll.dll!RtlCreateTagHeap+0xa7
ntdll.dll!LdrInitializeThunk+0xe
USER32.dll!DispatchMessageW+0x5c
RogueKiller_DEBUG.exe+0xfac5
RogueKiller_DEBUG.exe+0x1219
RogueKiller_DEBUG.exe+0x1eaae2
RogueKiller_DEBUG.exe+0x1ea98f
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36


[Tigzy]

I don't find the debug.log lines :/ Did you forget them?
What if you suspend the process with Process Explorer (context menu as well) before create the dump?

Because the stack trace is missing the symbols (that are private on my side)

[thisisu]

I don't find the debug.log lines :/ Did you forget them?

It's attached as debug.txt. The forums don't allow .log extension to be uploaded so I renamed it.

[Tigzy]

Gotcha

[Tigzy]

Any chance to get the stack trace of the other thread? Even without symbols, I know where it hangs.
But there's no reason to hang here, single string comparison :/

[thisisu]

Trying. Program won't hang for me again.

[Tigzy]

yeah, pretty hard to reproduce :/
If you say it doesn't hang everytime for you, then I can maybe reproduce.
Trying now

[Tigzy]

Stop Trying, I found weird stuff for DLLHost in the log :p
Looks like a dead lock, I'll investigate

[thisisu]

Yeah I've relaunched it about 40 times now without a single hiccup.

Attaching a picture where it killed a couple of processes (for the first time for me).

Code: [Select]

[00:05:0460] [WK] select FileName,AllowedPaths,OwnerName from WELL_KNOWN_FILES where "SearchFilterHost.exe" LIKE FileName
[00:05:0460] [WK] %WINDIR%\system32;%WINDIR%\syswow64
[00:05:0460] [WK] 0 - %WINDIR%\system32
[00:05:0460] [WK] 1 - %WINDIR%\syswow64
[00:05:0460] [WK] 0 - C:\Windows\System32 - \Device\HarddiskVolume2\Windows\System32
[00:05:0460] [WK] 1 - C:\Windows\SysWOW64 - \Device\HarddiskVolume2\Windows\System32
[00:05:0460] [KILL] Trying to kill...
[00:05:0460] [KILL] Try TerminateProcess...
[00:05:0460] [KILL] Open Snap...
[00:05:0460] [KILL] Snap -> 0x348
[00:05:0460] [KILL] Terminate process...
[00:05:0460] [KILL] OK!
[00:05:0460] [KILL] Handle closed!
[00:05:0460] [KILL] Returning TERMINATE_PROCESS...
[00:05:0460] [KILL] Killed : 1
[00:05:0460] [KILL] Kill finished : 1
[00:05:0476] [WK] select FileName,AllowedPaths,OwnerName from WELL_KNOWN_FILES where "SearchProtocolHost.exe" LIKE FileName
[00:05:0476] [WK] %WINDIR%\system32;%WINDIR%\syswow64
[00:05:0476] [WK] 0 - %WINDIR%\system32
[00:05:0476] [WK] 1 - %WINDIR%\syswow64
[00:05:0476] [WK] 0 - C:\Windows\System32 - \Device\HarddiskVolume2\Windows\System32
[00:05:0476] [WK] 1 - C:\Windows\SysWOW64 - \Device\HarddiskVolume2\Windows\System32
[00:05:0476] [KILL] Trying to kill...
[00:05:0476] [KILL] Try TerminateProcess...
[00:05:0476] [KILL] Open Snap...
[00:05:0476] [KILL] Snap -> 0x348
[00:05:0476] [KILL] Terminate process...
[00:05:0476] [KILL] OK!
[00:05:0476] [KILL] Handle closed!
[00:05:0476] [KILL] Returning TERMINATE_PROCESS...
[00:05:0476] [KILL] Killed : 1
[00:05:0476] [KILL] Kill finished : 1

[Tigzy]

Ok, Thanks.
I'll try to fix that too, the path isn't expanded as it should be :/

[thisisu]

You're welcome

[Tigzy]

Culprit has been found, and it has nothing to do with dllhost, or SearchHostFiler.
This is a new feature added recently (this is why the problem is recent), it's the "Killed process verification".
Looking into it now. I'll add some debug trace.

[thisisu]

Cool 

[Tigzy]

Problem has been identified
It's actually a problem of PID recycling, leading to an application deadlock while building the process tree.

When an application exits, its PID is recycled and can be reassigned to another process.
The bug appears in certain circumstances where we have a PID loop like this:

child ----> parent ----> parent of the parent ---> ...

process1 ----> process2 ----> process3 -----> process1 (former process4)

process4 has terminated, and its PID has been recycled and attributed to newly created process1.
So that we have an infinite child-parent loop, and the program was looking for the parent of process1 indefinitely.

What has changed:
Now, before looking for the parent, we look the creation date of the process and its parent.
The process must have been created AFTER the parent (logical), if the condition is not true, then the parent has been recycled and we attach the child on root node.

So, in clear, this will be fixed (hopefully, because I can't reproduce) in the next release.