aRwyT4GJb83NGAdvwFQgA/z6fFbX!sFnLfO/bQI/X6nZ2M813AoRFjCteY58gG63   
   YTWRbqOEkrhGCbiye+ALzJ9cJ165s6UMunCMKB8n!pZVr4wlWrx1J3VvW0uF20yJ   
   Vy7kSjW3608isQ==   
   properly   
   From: "Steven Levine"    
      
   On Sun, 7 Nov 2010 15:18:06 UTC, Lars Erdmann     
   wrote:   
      
   Hi Lars,   
      
   > > This would be easier if the .pu# did not imply that the kernel stack   
   > > was corrupted.  Does .pu# give sensible output wit your dump file?   
   > > What I see here is   
   > > # .pu#   
   > >   Slot  Pid  Ord  pPTDA    Name     pstkframe  CS:EIP        SS:ESP   
   > > cbargs   
   > > *003a# 0026 0001 fa1584e0 PMSHELL  %f9cccf40 ffef:0000c511   
   > > 0047:0008e948 000a   
       
   > This is what I get:   
   >   Slot  Pid  Ord  pPTDA    Name     pstkframe  CS:EIP        SS:ESP       
   cbargs   
   > *0045# 0026 0001 f95c1a78 PMSHELL  %f913af3c ffef:0000e3e1 003f:0007e978 000a   
      
   This is what I would expect, since we have the same exception.   
      
   I need to correct my original statement.  I now understand what this    
   output means.  The ss:esp value shown by .pu is not corrupted.  It is    
   a 32-bit linear address displayed thunked because cs points to a    
   16-bit segment.  Pmdf is doing the best it can, but the output was    
   confusing me until I thought a bit more about the code cs:ip was    
   pointing at.  If you thunk the ss:esp to a 32-bit linear address, it    
   will look as expected and point to the expected data on the ring3    
   stack.   
      
   > It therefore looks just as wrong. One observation: the same CS:EIP shows up   
   for a bunch of other   
   > processes. It's in kernel routine UT32_TARGET and it's a jump from a 16-bit   
   code segment to a 32-bit code segment.   
   > (the target of the jump is UT32_RETURN).   
      
   What you are looking at is the code in doscall1.dll that handles    
   transferring parameters between the user and kernel stacks for 32-bit    
   APIs that do not have an explicit call gate entry point.  The routine    
   that would receive control if the API code did not trap is   
      
   DOSCALL1 UT32_TARGET:    
   ffef:0000c50c 6736ff5b04     call      dword ptr ss:[ebx+04]    
   ffef:0000c511 66ea6477fc1f5b00 jmp       005b:1ffc7764    
      
   The call is to a 16-bit call gate and the jump is back to a 32-bit    
   segment containing the code that copies the values returned by the    
   16-bit API back on the user stack.   
      
   This is all part of the wrapper code in doscall1.dll that transform    
   32-bit APIs for processing by the corresponding 16-bit API.  In this    
   case th ring3 code invoked Dos32LoadModule and docall1.dll arranged    
   for this to be processed by the the 16-bit DosLoadModule API.   
      
   To make things more interesting, the guts of many of the 16-bit APIs,    
   DosLoadModule included, have been rewritten as 32-bit code, so at some   
   point, the DosLoadModule code will make a far call the the 32-bit code   
   that implements the guts of the API.   
      
   I can only suspect that this relatively complicated code path was part   
   of a transition plan to a fully 32-bit implementation that was never    
   completed.   
      
   I have some ideas why this implementation was chosen, but this is only   
   speculation on my part.   
      
   Steven   
      
      
   --    
   ---------------------------------------------------------------------   
   Steven Levine    
   eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com   
   ---------------------------------------------------------------------   
      
   --- Internet Rex 2.31   
    * Origin: The gateway at Omicron Theta (1:261/20.999)