IoAttachDeviceToDeviceStack

NTDEV
21

Hi,

I loaded dump file and used WinDbg command “!analyze -v” to check the result. I was confused by some context even after I checked the help file:

  1. “A device driver attempting to corrupt the system has been caught. This is
    because the driver was specified in the registry as being suspect (by the
    administrator) and the kernel has enabled substantial checking of this driver.
    If the driver attempts to corrupt the system”. ---- I can’t understand this paragraph. Can anybody help me to understand it and find possible solution?

  2. “Arguments:
    Arg1: 00000053, freeing memory where the caller has written past the end of the
    allocation, overwriting our stored virtual address”. ---- I don’t think I have used routines like free to do this. I believe the BSOD is caused by IoAttachDeviceToDeviceStack(pfdo,pdo). Because I have called pfdo in the routine and it works fine before IoAttachDeviceToDeviceStack, I guess the problem is pdo. Should I initialize pdo before IoAttachDeviceToDeviceStack? If so, how to do it? This pdo is a pointer from "NTSTATUS DrvAddDevice(IN PDRIVER_OBJECT DriverObject, IN PDEVICE_OBJECT pdo) and I did nothing to it in the program before IoAttachDeviceToDeviceStack.

  3. "WARNING: SystemResourcesList->Blink chain invalid. Resource may be corrupted, or already deleted.

1 total locks" ----- I can’t understand this. What does this “Blink” and “lock” mean?

I knew these questions maybe foolish, please don’t laugh at it. Thanks very much.

Here is the total WinDbg content:

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Parameter 1 = 0x1000 … 0x1020 - deadlock verifier error codes.
Typically the code is 0x1001 (deadlock detected) and you can
issue a ‘!deadlock’ KD command to get more information.
Arguments:
Arg1: 00000053, freeing memory where the caller has written past the end of the
allocation, overwriting our stored virtual address.
Arg2: 80588b09, base address of the allocation,
Arg3: 80589119, header,
Arg4: 868bb175, (reserved)

Debugging Details:

BUGCHECK_STR: 0xc4_53

WRITE_ADDRESS: 80588b09

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: System

LOCK_ADDRESS: 80552360 – (!locks 80552360)

Resource @ nt!PiEngineLock (0x80552360) Available

WARNING: SystemResourcesList->Flink chain invalid. Resource may be corrupted, or already deleted.

WARNING: SystemResourcesList->Blink chain invalid. Resource may be corrupted, or already deleted.

1 total locks

PNP_TRIAGE:
Lock address : 0x80552360
Thread Count : 0
Thread address: 0x00000000
Thread wait : 0x0

LAST_CONTROL_TRANSFER: from 8064d779 to 804f9aef

STACK_TEXT:
f88be8bc 8064d779 000000c4 00000053 80588b09 nt!KeBugCheckEx+0x1b
f88be8e4 80544ca5 80588b09 00000620 00000001 nt!ViFreeTrackedPool+0xf5
f88be930 80588c45 80588b09 00000000 82119008 nt!ExFreePoolWithTag+0xbf
f88be9a8 8058d2eb 82894de8 00000001 e15e82d4 nt!IopQueryDeviceResources+0x2ad
f88be9d4 8058db4f e15e82c0 00000001 f88bea24 nt!IopGetResourceRequirementsForAssignTable+0xd7
f88bea30 805908a4 f88bea90 f88bea6c 00000000 nt!IopAllocateResources+0x4f
f88bea88 80590a0c 00000001 e15e82c0 00000001 nt!IopAssignResourcesToDevices+0x100
f88beac0 8058761a 82119008 00000000 f88beb0d nt!IopProcessAssignResources+0xd6
f88bed1c 80587cae 82119008 00000001 00000000 nt!PipProcessDevNodeTree+0xa6
f88bed4c 804f675a 00000003 80552440 8055b3fc nt!PiRestartDevice+0x80
f88bed74 80534fe6 00000000 00000000 82aff3c8 nt!PipDeviceActionWorker+0x15e
f88bedac 805c5cce 00000000 00000000 00000000 nt!ExpWorkerThread+0x100
f88beddc 805421c2 80534ee6 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!ViFreeTrackedPool+f5
8064d779 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!ViFreeTrackedPool+f5

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlpa.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 45e53f9c

FAILURE_BUCKET_ID: 0xc4_53_W_nt!ViFreeTrackedPool+f5

BUCKET_ID: 0xc4_53_W_nt!ViFreeTrackedPool+f5

Followup: MachineOwner

kd> ln 8064d779
(8064d684) nt!ViFreeTrackedPool+0xf5 | (8064d780) nt!VerifierFreePoolWithTag
kd> ln 804f9aef
(804f9ad4) nt!KeBugCheckEx+0x1b | (804f9af8) nt!KeClearTimer

22

> I only have one computer to debug my driver, so I can’t use windbg.

  1. analyze the postmortem crash dump using “windbg -z” and “!analyze -v”
  2. MS Virtual PC 2007 is a free download
  3. get yourself a second machine

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

23

xxxxx@hotmail.com wrote:

I loaded dump file and used WinDbg command “!analyze -v” to check the result. I was confused by some context even after I checked the help file:

  1. “A device driver attempting to corrupt the system has been caught. This is
    because the driver was specified in the registry as being suspect (by the
    administrator) and the kernel has enabled substantial checking of this driver.
    If the driver attempts to corrupt the system”. ---- I can’t understand this paragraph. Can anybody help me to understand it and find possible solution?

This is just the generic description of the C4 bugcheck. It doesn’t
offer you any debugging information.

  1. “Arguments:
    Arg1: 00000053, freeing memory where the caller has written past the end of the
    allocation, overwriting our stored virtual address”. ---- I don’t think I have used routines like free to do this. I believe the BSOD is caused by IoAttachDeviceToDeviceStack(pfdo,pdo). Because I have called pfdo in the routine and it works fine before IoAttachDeviceToDeviceStack, I guess the problem is pdo. Should I initialize pdo before IoAttachDeviceToDeviceStack? If so, how to do it? This pdo is a pointer from "NTSTATUS DrvAddDevice(IN PDRIVER_OBJECT DriverObject, IN PDEVICE_OBJECT pdo) and I did nothing to it in the program before IoAttachDeviceToDeviceStack.

This is just saying a buffer has been overwritten. It doesn’t
necessarily mean you overwrote one of your OWN buffers. It could mean
you supplied a structure that had not been correctly set up, for
example. It could mean you passed a garbage pointer.

  1. "WARNING: SystemResourcesList->Blink chain invalid. Resource may be corrupted, or already deleted.

1 total locks" ----- I can’t understand this. What does this “Blink” and “lock” mean?

Many of the system APIs (as well as many drivers) use the doubly-linked
list routines in the DDK. Those routines use a link structure called
LIST_ENTRY, and the forward and backward pointers are called Flink and
Blink (“forward link” and “backward link”). This is just saying that
some of the linked list pointers in the system resources list were among
the parts that got trashed.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

24

wrote in message news:xxxxx@ntdev…

> 1. “A device driver attempting to corrupt the system has been caught.
> This is
> because the driver was specified in the registry as being suspect (by the
> administrator) and the kernel has enabled substantial checking of this
> driver.
> If the driver attempts to corrupt the system”.
---- I can’t understand this paragraph. Can anybody help me to understand it
and find possible solution?

Explanation: The driver verifier was enabled on this driver, and it catched
a violation.

> 3. “WARNING: SystemResourcesList->Blink chain invalid. Resource may be
> corrupted, or already deleted.
> 1 total locks” ----- I can’t understand this. What does this
> “Blink” and “lock” mean?

Blink: Back link

The locks thing is related to list of of locks owned by the faulting
process (which is SYSTEM), that !analyse does.

Bottom line… this report is not very informative as is, but gives you some
directions.

Good luck.
–PA

25

Thanks for all of your replies.