AMD64 test machine test machine causing Vista 64 failures

NTDEV
1

Having problems with a Vista 64 SUT, eg not even adding our device for
testing and carrying out the hard disk system DTM test causes the system
to fail, eg blue screen and always complains about the atapi driver (if
debugger attached).

This same machine has been used for XP 64 & 2003 64 testing and passes
without problem when our device is tested. Currently using a different
Vista 64 bit machine and testing has passed - not understanding this as
it points to no problems in our driver.

So have applied all MS updates and nvidia drivers (all whql’d) so why
should this systems fail? Is there anyone at MS I can send machine
info/logs to? When the debugger is attached it dumps:

DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for
too long a time
Arg2: fffffa8000d32960, Physical Device Object of the stack
Arg3: fffffa8001753060, Functional Device Object of the stack
Arg4: fffffa8001aecc60, The blocked IRP

Debugging Details:

DRVPOWERSTATE_SUBCODE: 3
DEVICE_OBJECT: fffffa8000d32960
DRIVER_OBJECT: fffffa8000a92a50
IMAGE_NAME: atapi.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4549bc82
MODULE_NAME: atapi
FAULTING_MODULE: fffff9800053d000 atapi

This is a real pain as ideally want 2 test machines - one for 32 bit OS
and one for 64 bit OS testing, maybe will just have to swap my 64 bit
machine for the faulty 64 bit machine?

Any ideas? TIA

Daryl

2

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Daryl Baker[SMTP:xxxxx@des.co.uk]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, September 27, 2007 11:54 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] AMD64 test machine test machine causing Vista 64 failures

So have applied all MS updates and nvidia drivers (all whql’d) so why
should this systems fail?

Welcome to Windows world :wink: This bugcheck means there is a bug in PnP and Power IRPs processing. Usually caused by race conditions and that’s why it can be reproduced on some machines only. Race conditions can be influenced by any timing change.

This problem may be caused by driver listed in the WinDbg analysis but also by drivers below it. I saw it for my USB driver which was listed as a culprit but the real bug was in OS drivers below.

Try to search KB to see if there isn’t a hotfix for this problem (what Joseph posted is very probably unrelated; this is one of common bugchecks). You can also try to analyse problem a bit; use !irp command for blocked IRP to see what kind of IRP was blocked. If you can’t find a fix, report the bug via PSS.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]