none
How can I tell if the stack of a kernel thread is paged or not? RRS feed

  • Question

  • The platform: Windows 8.1 64 bit.

    I suspect a stack-allocated buffer used for URB transfer buffer is not "resident". The thread in question is for PnP operations created by the system and named "System".

    How can I tell if a stack is resident (non-paged) with WinDbg?

    In addition, is there a documented rule stating that URB transfer buffer may not be allocated on stack?

    I am afraid that the buffer would be used by DMA and lead to problems.

    P.S. I used "!stacks 2" to show the information of all kernel stacks. It showed that some of the kernel stacks were paged out. Looks like the possibility does exist.

    • Edited by muraliz Thursday, September 10, 2015 9:52 AM
    Thursday, September 10, 2015 9:47 AM

Answers

  • Kernel stacks are non-paged.  Mostly people don't allocate buffers on the stack, since the stack is a very limited size, and all the drivers in the stack share that limited size.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    • Marked as answer by muraliz Thursday, September 10, 2015 1:04 PM
    • Unmarked as answer by muraliz Tuesday, September 15, 2015 6:58 AM
    • Marked as answer by muraliz Wednesday, September 30, 2015 8:49 AM
    Thursday, September 10, 2015 10:55 AM

All replies

  • Kernel stacks are non-paged.  Mostly people don't allocate buffers on the stack, since the stack is a very limited size, and all the drivers in the stack share that limited size.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    • Marked as answer by muraliz Thursday, September 10, 2015 1:04 PM
    • Unmarked as answer by muraliz Tuesday, September 15, 2015 6:58 AM
    • Marked as answer by muraliz Wednesday, September 30, 2015 8:49 AM
    Thursday, September 10, 2015 10:55 AM

  • Thank you.

    It appears that this has been documented (not emphasized though) on MSDN.

    https://msdn.microsoft.com/en-us/library/windows/hardware/ff540357%28v=vs.85%29.aspx

    TransferBuffer

    Pointer to a resident buffer for the transfer or is NULL if an MDL is supplied in TransferBufferMDL.

    https://msdn.microsoft.com/en-us/library/windows/hardware/ff539004%28v=vs.85%29.aspx

     From the perspective of a driver, buffers come in one of two varieties:

    Paged buffers, which may or may not be resident in memory.
    Non-paged buffers, which must be resident in memory.



    • Edited by muraliz Thursday, September 10, 2015 1:04 PM
    Thursday, September 10, 2015 12:57 PM
  • what bugcheck code and output of !analyze -f are you seeing? Many bugchecks can read as if you are touching pagable memory when in fact the memory access that is faulting is a completely invalid pointer (NULL or freed pointer)

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, September 10, 2015 5:32 PM
  • 3: kd> !analyze -f
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    Use !analyze -v to get detailed debugging information.

    BugCheck 7E, {ffffffffc0000005, fffff800f3df65dc, ffffd0018afccd88, ffffd0018afcc590}

    Probably caused by : USBD.SYS ( USBD!USBD_ParseDescriptors+4c )

    Followup: MachineOwner
    ---------

    Yes, the direct cause of the bug is actually related to invalid pointer (as an argument).

    But it is observed that the buffer used for storing the configuration descriptor being emptied (zeroed), which is supposed to be a valid one after a "successful" URB call.

    The code for URB I/O as follows:

    NTSTATUS SendAwaitUrb(PDEVICE_OBJECT fdo, PURB urb)
    {							// SendAwaitUrb
    	PAGED_CODE();
    	ASSERT(KeGetCurrentIrql() == PASSIVE_LEVEL);
    	PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo->DeviceExtension;
    
    	KEVENT event;
    	KeInitializeEvent(&event, NotificationEvent, FALSE);
    
    	IO_STATUS_BLOCK iostatus;
    	PIRP Irp = IoBuildDeviceIoControlRequest(IOCTL_INTERNAL_USB_SUBMIT_URB,
    		pdx->LowerDeviceObject, NULL, 0, NULL, 0, TRUE, &event, &iostatus);
    
    	if (!Irp)
    	{
    		KdPrint((DRIVERNAME " - Unable to allocate IRP for sending URB\n"));
    		return STATUS_INSUFFICIENT_RESOURCES;
    	}
    
    	PIO_STACK_LOCATION stack = IoGetNextIrpStackLocation(Irp);
    	stack->Parameters.Others.Argument1 = (PVOID) urb;
    	NTSTATUS status = IoCallDriver(pdx->LowerDeviceObject, Irp);
    	if (status == STATUS_PENDING)
    	{
    		KeWaitForSingleObject(&event, Executive, KernelMode, FALSE, NULL);
    		status = iostatus.Status;
    	}
    	return status;
    }							// SendAwaitUrb
    

    Friday, September 11, 2015 2:47 AM
  • According to this: https://msdn.microsoft.com/en-us/library/windows/hardware/ff541920%28v=vs.85%29.aspx

    Kernel stacks are still possible to be paged though.

    Friday, September 11, 2015 11:51 AM
  • Yes the kernel stack can be paged if the thread is inactive.  But for all practical purposes you can rely on the stack being there.  It would basically have to be a situation where you completely handoff to another entity a pointer to a buffer on the stack, for this to be seen.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Thursday, September 17, 2015 5:28 PM
  • How about giving us the full !analyze -v for the crash, and since you are concerned about a buffer on the stack the address of that buffer?


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Thursday, September 17, 2015 5:29 PM
  • I am sorry for replying late.

    I think I can somehow confidently exclude that from the possibilities, because I can reproduce the problem within seconds now, even with a heap allocated buffer.

    Wednesday, September 30, 2015 8:49 AM