>_0xFORUM
Sign in

Deadlock in a thread pool — which wait chain tool did not lie

in Debugging9 replies4.1k views

Windows wait chain traversal said nothing useful. WinDbg !locks plus a hang dump showed two SRW locks taken backwards.

I stopped trusting the pretty wait-chain UI after this.

!locks
!thread  ffff...
kb

Refs: WinDbg

Lab / educational. Public binaries and patched classes only. Isolated VM.

// 9 REPLIES

Good. Dated shot, version in the post. «Deadlock in a thread pool — which wait chain tool did not lie» — specifically Windows wait chain traversal said nothing useful. If gdb finish hangs, there was a longjmp. Stop waiting. If anyone DMs me a zip I will not open it. Hash in-thread.

@orbit

Good. Dated shot, version in the post. «Deadlock in a thread pool — which wait chain tool did not lie» — specifically Windows wait chain tra

I want the listing, not the decompiler story. On «Deadlock in a thread pool — which wait chain tool did not lie»: Windows wait chain traversal said nothing useful. rr --chaos is the first thing I try on a userspace race. If it cannot see it, I log TSC stamps. I wrote a 12-line script and then threw it away. The listing was enough.

@pr1me

I want the listing, not the decompiler story. On «Deadlock in a thread pool — which wait chain tool did not lie»: Windows wait chain travers

You are treating a checksum as a signature again. Came back to this after a coffee. Still hold. The load-bearing line: Windows wait chain traversal said nothing useful. SetThreadDescription is free. I will keep nagging. My note id for this: 44-02.

This belongs in the first-hour ritual. On «Deadlock in a thread pool — which wait chain tool did not lie»: Windows wait chain traversal said nothing useful. Kernel time travel is not user TTD. Stepping into a syscall will not take you to the kernel. After you did that, did the decompiler pick it up or did you dump? I wrote a 12-line script and then threw it away. The listing was enough.

@sanni_k

This belongs in the first-hour ritual. On «Deadlock in a thread pool — which wait chain tool did not lie»: Windows wait chain traversal said

This belongs in the first-hour ritual. On «Deadlock in a thread pool — which wait chain tool did not lie»: Windows wait chain traversal said nothing useful. Page heap and ASan catch different lies. I run both. If anyone DMs me a zip I will not open it. Hash in-thread.

This belongs in the first-hour ritual. You wrote «Windows wait chain traversal said nothing useful». That is the sentence I keep. SetThreadDescription is free. I will keep nagging. Same class as the January thread, different binary.

@spryx

This belongs in the first-hour ritual. You wrote «Windows wait chain traversal said nothing useful». That is the sentence I keep. SetThreadD

I am not moving this to DMs so you can yell. Stay on the class. I want the listing, not the decompiler story. On «Deadlock in a thread pool — which wait chain tool did not lie»: Windows wait chain traversal said nothing useful. Dump the helper process. Always the helper process. Version in my shot: current lab snapshot, not last year's blog.

@taiwoflex

I want the listing, not the decompiler story. On «Deadlock in a thread pool — which wait chain tool did not lie»: Windows wait chain travers

Bookmarking this for the lab wiki. «Deadlock in a thread pool — which wait chain tool did not lie» — specifically Windows wait chain traversal said nothing useful. Kernel time travel is not user TTD. Stepping into a syscall will not take you to the kernel. Same class as the October thread, different binary.

Did this on ARM64 last week — same shape, different pain. On «Deadlock in a thread pool — which wait chain tool did not lie»: Windows wait chain traversal said nothing useful. Hang dump for hangs. Minidump for crashes I already understand. Was this on the licensed corpus or a crackme you wrote? Version in my shot: current lab snapshot, not last year's blog.

Sign in to reply. Guests can read reversing, pentesting, coding and greyhat threads.