CIDHandles bug ?

Hello,

I am playing with DebugView from SysInternals and i noticed that ROS
KeBugChecks in NtOpenProccess (line 878):

        if (ClientId->UniqueThread)
        {
            /* Get the Process */
            if (ClientId->UniqueThread == (HANDLE)-1) KEBUGCHECK(0);  
   <===== HERE
            DPRINT("Opening by Thread ID: %x\n", ClientId->UniqueThread);
            Status = PsLookupProcessThreadByCid(ClientId,
                                                &Process,
                                                &Thread);
            DPRINT("Found: %x\n", Process);

It looks like that UniqueThread holds value -1. I look in
NtCreateThread and it has CID handle creation implemented
(PsCreateCidHandle and friends ...)

I only get KeBugCheck with DebugView (another exes run properly). If
you force a false evaluation (for example:  if
((ClientId->UniqueThread)&&(0))) NtOpenProcess does a LookUp  by
proccess cid and DebugView run fine

Any idea?

[Thomas Weidenmueller]

open.proyects(a)gmail.com wrote:
>   Hello,
>  
>  I am playing with DebugView from SysInternals and i noticed that ROS
>  KeBugChecks in NtOpenProccess (line 878):
>  
>          if (ClientId->UniqueThread)
>          {
>              /* Get the Process */
>              if (ClientId->UniqueThread == (HANDLE)-1) KEBUGCHECK(0);  
>     <===== HERE
>              DPRINT("Opening by Thread ID: %x\n", ClientId->UniqueThread);
>              Status = PsLookupProcessThreadByCid(ClientId,
>                                                  &Process,
>                                                  &Thread);
>              DPRINT("Found: %x\n", Process);
>  
>  It looks like that UniqueThread holds value -1. I look in
>  NtCreateThread and it has CID handle creation implemented
>  (PsCreateCidHandle and friends ...)
>  
>  I only get KeBugCheck with DebugView (another exes run properly). If
>  you force a false evaluation (for example:  if
>  ((ClientId->UniqueThread)&&(0))) NtOpenProcess does a LookUp  by
>  proccess cid and DebugView run fine
>  
>  Any idea? 
I just fixed it, update to rev. 15230. This was clearly for debugging
purpose and was accidently committed, it shouldn't be there.

Best Regards,
Thomas