Re: TIMER_OR_DPC_INVALID - Kernel timer or DPC used incorrectly

OSR_Community_User · July 10, 2013, 5:58pm

I’ve not seen this error before, so I’m guessing. Are you having any
paged code in your driver? If so, a timer DPC must NOT be paged, and must
be made permanently resident, because it must be present when it is
called, and a page fault will be fatal. Reading the dump suggests that
the kernel, instead of taking a generic BSOD on “access fault”, is telling
you some more detailed information. It appears that it has checked a
range of addresses at the nominal address of the DPC and found them
lacking. Such as being non-existent, or paged out.

If you feel a compulsion to do a driver with paged code, the correct
approach, in my opinion, is to NOT used any paged code until the driver is
known to be functioning correctly. THEN, and only then, optimize it by
making pageable parts pageable. That way, you know where the potential
failure points are, and that they are artifacts of using pageable code.
joe

Hi,

I am having hard time with a crash. I have analyzed it using WinDbg and
this is what I have got,

=======================================
Kernel Complete Dump File: Full address space is available

Windows Server 2008/Windows Vista Kernel Version 6002 (Service Pack 2) MP
(4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 6002.18686.amd64fre.vistasp2_gdr.120824-0336
Machine Name:
Kernel base = 0xfffff80002259000 PsLoadedModuleList = 0xfffff8000241ddd0
Debug session time: Thu Jun 27 18:39:34.320 2013 (UTC + 5:30)
System Uptime: 0 days 0:29:29.340

Loading Kernel Symbols
…
…
…
Loading User Symbols

Loading unloaded module list
…
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C7, {0, fffffa60040ab260, fffffa60040ab260, fffffa60040ab2a0}

Probably caused by : testflt.sys ( testflt!InitializeDelayedEvent+124 )

Followup: MachineOwner

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

TIMER_OR_DPC_INVALID (c7)
Kernel timer or DPC used incorrectly.
Arguments:
Arg1: 0000000000000000, Timer object found in memory which must not
contain such items.
Arg2: fffffa60040ab260, Address of the timer object.
Arg3: fffffa60040ab260, Start of memory range being checked.
Arg4: fffffa60040ab2a0, End of memory range being checked.

Debugging Details:

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xC7

PROCESS_NAME: System

CURRENT_IRQL: c

TAG_NOT_DEFINED_c000000f: FFFFF800032D7FB0

LAST_CONTROL_TRANSFER: from fffff8000233d5d3 to fffff800022b0ad0

STACK_TEXT:
fffff800032d19a8 fffff8000233d5d3 : 00000000000000c7 0000000000000000
fffffa60040ab260 fffffa60040ab260 : nt!KeBugCheckEx
fffff800032d19b0 fffff800026aa89e : 0000000000000000 0000000000000002
0000000000000000 fffffa60040ab260 : nt!KeCheckForTimer+0x153
fffff800032d1a00 fffffa600408a390 : fffffa8005d102d0 0000000000000002
0000000000000000 0000000000000001 : nt!VerifierKeInitializeTimerEx+0x2e
fffff800032d1a30 fffff800022b49fd : fffff800032d1ad8 0000000000000000
0000000000000003 0000000000000003 : testflt!InitializeDelayedEvent+0x124
[e:\wd\cat\projects\novashield\ns2.0\sdk\source\sdk\safeengine\policy\processstate.c
@ 542]
fffff800032d1a70 fffff800022b3e18 : fffff800032d1cd0 0000000000000002
fffff800032d1cc8 0000000000000010 : nt!KiTimerListExpire+0x30d
fffff800032d1ca0 fffff800022b45af : 000004f9f4dd0787 0000000000000000
fffff80000000010 fffff800023cfa80 : nt!KiTimerExpiration+0x1d8
fffff800032d1d10 fffff800022b4ed2 : fffff800023cc680 fffff800023cc680
0000000000000000 fffff800023d1b80 : nt!KiRetireDpcList+0x1df
fffff800032d1d80 fffff80002484860 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiIdleLoop+0x62
fffff800032d1db0 00000000fffff800 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!zzz_AsmCodeRange_End+0x4
fffff800032cb0b0 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0068000000000000 : 0xfffff800

STACK_COMMAND: kb

FOLLOWUP_IP:
testflt!InitializeDelayedEvent+124 [e:\wd\testflt\testflt.c @ 542]
fffffa600408a390 488b15510c0200 mov rdx,qword ptr [testflt!gShortTime (fffffa60040aafe8)]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: testflt!InitializeDelayedEvent+124

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: testflt

IMAGE_NAME: testflt.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 51a5de86

FAILURE_BUCKET_ID: X64_0xC7_VRF_testflt!InitializeDelayedEvent+124

BUCKET_ID: X64_0xC7_VRF_testflt!InitializeDelayedEvent+124

Followup: MachineOwner

=======================================

Any comment could help me fixing the crash.

Best regards,
Sushilkumar.

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · July 10, 2013, 6:01pm

And, of course, there is the possibility that the list is corrupted by
generic memory damage, such as using a stale pointer or overrunning a
buffer. These should be considered also, although your suggestion is
certainly the simplest to check.
joe

Basically this is a type of timer list corruption. Any change you are
trying
to initialize a timer twice? You can use !timer in the debugger to see the
current list of timers.

-scott
OSR

wrote in message news:xxxxx@ntfsd…

Hi,

I am having hard time with a crash. I have analyzed it using WinDbg and
this
is what I have got,

=======================================
Kernel Complete Dump File: Full address space is available

Windows Server 2008/Windows Vista Kernel Version 6002 (Service Pack 2) MP
(4
procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 6002.18686.amd64fre.vistasp2_gdr.120824-0336
Machine Name:
Kernel base = 0xfffff80002259000 PsLoadedModuleList = 0xfffff8000241ddd0
Debug session time: Thu Jun 27 18:39:34.320 2013 (UTC + 5:30)
System Uptime: 0 days 0:29:29.340

Loading Kernel Symbols
…
…
…
Loading User Symbols

Loading unloaded module list
…
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C7, {0, fffffa60040ab260, fffffa60040ab260, fffffa60040ab2a0}

Probably caused by : testflt.sys ( testflt!InitializeDelayedEvent+124 )

Followup: MachineOwner

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

TIMER_OR_DPC_INVALID (c7)
Kernel timer or DPC used incorrectly.
Arguments:
Arg1: 0000000000000000, Timer object found in memory which must not
contain
such items.
Arg2: fffffa60040ab260, Address of the timer object.
Arg3: fffffa60040ab260, Start of memory range being checked.
Arg4: fffffa60040ab2a0, End of memory range being checked.

Debugging Details:

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xC7

PROCESS_NAME: System

CURRENT_IRQL: c

TAG_NOT_DEFINED_c000000f: FFFFF800032D7FB0

LAST_CONTROL_TRANSFER: from fffff8000233d5d3 to fffff800022b0ad0

STACK_TEXT:
fffff800032d19a8 fffff8000233d5d3 : 00000000000000c7 0000000000000000
fffffa60040ab260 fffffa60040ab260 : nt!KeBugCheckEx
fffff800032d19b0 fffff800026aa89e : 0000000000000000 0000000000000002
0000000000000000 fffffa60040ab260 : nt!KeCheckForTimer+0x153
fffff800032d1a00 fffffa600408a390 : fffffa8005d102d0 0000000000000002
0000000000000000 0000000000000001 : nt!VerifierKeInitializeTimerEx+0x2e
fffff800032d1a30 fffff800022b49fd : fffff800032d1ad8 0000000000000000
0000000000000003 0000000000000003 : testflt!InitializeDelayedEvent+0x124
[e:\wd\cat\projects\novashield\ns2.0\sdk\source\sdk\safeengine\policy\processstate.c
@ 542]
fffff800032d1a70 fffff800022b3e18 : fffff800032d1cd0 0000000000000002
fffff800032d1cc8 0000000000000010 : nt!KiTimerListExpire+0x30d
fffff800032d1ca0 fffff800022b45af : 000004f9f4dd0787 0000000000000000
fffff80000000010 fffff800023cfa80 : nt!KiTimerExpiration+0x1d8
fffff800032d1d10 fffff800022b4ed2 : fffff800023cc680 fffff800023cc680
0000000000000000 fffff800023d1b80 : nt!KiRetireDpcList+0x1df
fffff800032d1d80 fffff80002484860 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiIdleLoop+0x62
fffff800032d1db0 00000000fffff800 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!zzz_AsmCodeRange_End+0x4
fffff800032cb0b0 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0068000000000000 : 0xfffff800

STACK_COMMAND: kb

FOLLOWUP_IP:
testflt!InitializeDelayedEvent+124 [e:\wd\testflt\testflt.c @ 542]
fffffa600408a390 488b15510c0200 mov rdx,qword ptr [testflt!gShortTime (fffffa60040aafe8)]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: testflt!InitializeDelayedEvent+124

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: testflt

IMAGE_NAME: testflt.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 51a5de86

FAILURE_BUCKET_ID: X64_0xC7_VRF_testflt!InitializeDelayedEvent+124

BUCKET_ID: X64_0xC7_VRF_testflt!InitializeDelayedEvent+124

Followup: MachineOwner

=======================================

Any comment could help me fixing the crash.

Best regards,
Sushilkumar.

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · July 11, 2013, 3:12am

> If you feel a compulsion to do a driver with paged code, the correct

approach, in my opinion, is to NOT used any paged code until the driver is
known to be functioning correctly. THEN, and only then, optimize it by
making pageable parts pageable.

Well, the rules are rather simple. Only the stuff never ever called at >= DISPATCH can be pageable. This includes the stuff called with a spinlock held.

Also, the pagefile path cannot be pageable too

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · July 11, 2013, 3:54am

>> If you feel a compulsion to do a driver with paged code, the correct

> approach, in my opinion, is to NOT used any paged code until the driver
> is
> known to be functioning correctly. THEN, and only then, optimize it by
> making pageable parts pageable.

Well, the rules are rather simple. Only the stuff never ever called at >=
DISPATCH can be pageable. This includes the stuff called with a spinlock
held.

That rule looks “simple” only to those of us who have really understood
the concept of IRQL level and can instantly recognize the symptoms of an
IRQL-level violation. And there’s little excuse for that these days
because PreFAST (or whatever the nom-du-jour is this week) should detect
these violations. But the number of times I’ve seen code of the form

A(); B(); C();

end up being

A(); KeASL(); B(); KeRSL(); C();

crash because B(); did something that required PASSIVE_LEVEL is far too
high. Or that someone working in a subroutine call by B(); adds a
P_L-only action. Sometimes these errors don’t show up until the software
has been deployed for months. Using DV and asking it to make all P_L code
and data disappear is a critical QA test. I’ve seen a number of failures
that don’t turn up until async I/O is used, because this forces some code
that by accident was always called at P_L in the synchronous I/O model to
be called at D_L in the async mode (the next packet being started from a
completion routine, for example). Saying it is “simple” is misleading,
because you have to understand all the /potential/ paths that execute each
function, and be sure that they are all guaranteed to be at P_L. The
outcome is frequently not-robust-under-maintenance unless you employ
PreFAST, SDV, and DV as part of the release methodology. So if someone
has to ask the question, the probability that the person posing the
question has already made at least one, if not more, of these errors
begins to closely approximate 1.0. The probability that that person will
ask about a “crash” in this NG also begins to approximate 1.0. Which is
why a beginner should never attempt paged code or data unless there is an
utterly compellling reason to build it in with the first running version.
There rarely is. So keep everything non-paged until convinced the driver
actually works without any IRQL violations. Then start making code and
data pageable, and test under memory stress conditions. If it worked
before, and doesn’t work now, you’ve got a pretty good idea that there is
a lurking IRQL violation which could not be triggered on the 16GB
development machine of the developer’s platform, but easily happens on the
4GB end-user server which is also running SQL Server, Oracle, IIS, Apache,
or other massive app(s).

BTW, I have all too often made an equivalent error working in
multithreaded apps in user space, and ended up with a deadlock. I can
sort of forgive myself the first instance of this error, but that was
something like 20 years ago, and I’ve probably committed it a dozen times
in the intervening period. That latter statistic is embarrassing.
joe

Also, the pagefile path cannot be pageable too

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer