Unsolicited code review: Mixing OS-native thread functions with Go's runtime is probably dangerous #2
Description
I was curious why there's any need for dealing with native threads and had a closer look. While running NtQueryObject that might hang on its own thread is a clever workaround, I am afraid that the Go runtime may behave in unexpected ways when a thread that had been subscribed to a channel suddenly disappears because it has been killed using kernel32.TerminateThread, without the runtime's knowledge.
I would try encapsulating only those NtQueryObject calls that might fail (because it has one of the four magic access attributes) in individual, separate threads.