Validity of access token and Bug Check 7A

Hi,
In the following code,

PVOID pAccessToken = NULL;

pAccessToken = PsReferencePrimaryToken(PsGetCurrentProcess());

status = ObOpenObjectByPointer( pAccessToken, 0, NULL, TOKEN_ALL_ACCESS,
NULL, KernelMode, &tokenHandle );

I got a BugCheck 7A, {c0385298, c000000d, e14a6000, 3fe0880}
inside ObOpenObjectByPointer() in a rare case. When I looked at the
process that was running, it turned out to be a user level process. But,
when I did a !token on the token for this process, it showed me SYSTEM. Is
it correct to assume that the access token is invalid? Is there any way to
check if the access token is valid or not?

if the access token is valid, is there any other possible cause for
getting this BSOD? Ours is a filter driver. The stack is as follows:

ChildEBP RetAddr Args to Child
b9fe282c 80510a42 8192ad00 c0385298 e14a6000
nt!MiWaitForInPageComplete+0x1f7
b9fe2870 8051a0c4 00000000 e14a6000 c0385298 nt!MiDispatchFault+0x272
b9fe28bc 80537cc6 00000000 00000000 00000000 nt!MmAccessFault+0x67b
b9fe28bc 8056b9c5 00000000 00000000 00000000 nt!KiTrap0E+0xc3
b9fe294c 8056d408 fac11b08 00000214 000f01ff
nt!ExpLookupHandleTableEntry+0x2f
b9fe29ac 8056d353 fac11b08 b9fe29d4 000f01ff
nt!ExpAllocateHandleTableEntry+0x246
b9fe29f0 8056f58e fac11b08 b9fe2a24 e2f25910 nt!ExCreateHandle+0x4d
b9fe2a38 80574870 00000001 e2f25910 fac11b08 nt!ObpCreateHandle+0x182
b9fe2b04 b9aa60ea e2f25910 00000000 00000000 nt!ObOpenObjectByPointer+0xac
b9fe2b3c b9a9b570 87de0040 81194b68 00000001
ArkFmon!ArkGetSidFromProcess+0x1b
b9fe2b68 b9a9b271 ff005000 8186a828 83f69a98 ArkFmon!GetFullPath+0x2c0
b9fe2b90 b9a95da5 8186a828 83f69a98 ff0050c8
ArkFmon!ArkFmonGetFilePath+0x51
b9fe2c60 b9a96ee1 83f699e0 81cba008 83f699e0 ArkFmon!ArkFmonFilter+0x126
b9fe2c98 804ef61f 83f699e0 81cba008 8186a828 ArkFmon!ArkFmonDispatch+0x33
b9fe2cac 804f0964 80244020 ff7eb020 80673f10 nt!IopfCallDriver+0x35
b9fe2cc0 80510a0d 8186a828 ffb1f340 ffb1f320 nt!IoPageRead+0xb1
b9fe2d00 8051a7be 00000000 0085fe0c c000217c nt!MiDispatchFault+0x23d
b9fe2d4c 80537cc6 00000000 0085fe0c 00000001 nt!MmAccessFault+0xc3a
b9fe2d4c 77f82829 00000000 0085fe0c 00000001 nt!KiTrap0E+0xc3
0085fe58 00000000 00000000 00000000 00000000 +0x77f82829

Thanks,

Rini

0x7A is KERNEL_DATA_INPAGE_ERROR. This would suggest that the paging I/O
operation sent by MiDispatchFault failed to be completed successfully. The
second parameter is the status code of the I/O operation - 0xC000000D -
which is STATUS_INVALID_PARAMETER.

Thus, I’d conclude that your filter driver is interfering with the
IRP_MJ_READ operation and causing it to fail in the FSD. The one thing I
found odd is that the failing address (0x3fe0880) would correspond to a USER
address, not a KERNEL address, which I thought was a bit odd…

FYI. The debugger documentation for this bug check is pretty clear:

Parameter Description
1 Page Table Entry (PTE) address
2 Error status (usually an I/O status code)
3 Virtual address
4 Virtual address that could not be paged into memory

That’s how I interpreted the crash you specified at least.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@yahoo.com [mailto:xxxxx@yahoo.com]
Sent: Wednesday, March 20, 2002 10:21 PM
To: File Systems Developers
Subject: [ntfsd] Validity of access token and Bug Check 7A

Hi,
In the following code,

PVOID pAccessToken = NULL;

pAccessToken = PsReferencePrimaryToken(PsGetCurrentProcess());

status = ObOpenObjectByPointer( pAccessToken, 0, NULL, TOKEN_ALL_ACCESS,
NULL, KernelMode, &tokenHandle );

I got a BugCheck 7A, {c0385298, c000000d, e14a6000, 3fe0880}
inside ObOpenObjectByPointer() in a rare case. When I looked at the
process that was running, it turned out to be a user level process. But,
when I did a !token on the token for this process, it showed me SYSTEM. Is
it correct to assume that the access token is invalid? Is there any way to
check if the access token is valid or not?

if the access token is valid, is there any other possible cause for
getting this BSOD? Ours is a filter driver. The stack is as follows:

ChildEBP RetAddr Args to Child
b9fe282c 80510a42 8192ad00 c0385298 e14a6000
nt!MiWaitForInPageComplete+0x1f7
b9fe2870 8051a0c4 00000000 e14a6000 c0385298 nt!MiDispatchFault+0x272
b9fe28bc 80537cc6 00000000 00000000 00000000 nt!MmAccessFault+0x67b
b9fe28bc 8056b9c5 00000000 00000000 00000000 nt!KiTrap0E+0xc3
b9fe294c 8056d408 fac11b08 00000214 000f01ff
nt!ExpLookupHandleTableEntry+0x2f
b9fe29ac 8056d353 fac11b08 b9fe29d4 000f01ff
nt!ExpAllocateHandleTableEntry+0x246
b9fe29f0 8056f58e fac11b08 b9fe2a24 e2f25910 nt!ExCreateHandle+0x4d
b9fe2a38 80574870 00000001 e2f25910 fac11b08 nt!ObpCreateHandle+0x182
b9fe2b04 b9aa60ea e2f25910 00000000 00000000 nt!ObOpenObjectByPointer+0xac
b9fe2b3c b9a9b570 87de0040 81194b68 00000001
ArkFmon!ArkGetSidFromProcess+0x1b
b9fe2b68 b9a9b271 ff005000 8186a828 83f69a98 ArkFmon!GetFullPath+0x2c0
b9fe2b90 b9a95da5 8186a828 83f69a98 ff0050c8
ArkFmon!ArkFmonGetFilePath+0x51
b9fe2c60 b9a96ee1 83f699e0 81cba008 83f699e0 ArkFmon!ArkFmonFilter+0x126
b9fe2c98 804ef61f 83f699e0 81cba008 8186a828 ArkFmon!ArkFmonDispatch+0x33
b9fe2cac 804f0964 80244020 ff7eb020 80673f10 nt!IopfCallDriver+0x35
b9fe2cc0 80510a0d 8186a828 ffb1f340 ffb1f320 nt!IoPageRead+0xb1
b9fe2d00 8051a7be 00000000 0085fe0c c000217c nt!MiDispatchFault+0x23d
b9fe2d4c 80537cc6 00000000 0085fe0c 00000001 nt!MmAccessFault+0xc3a
b9fe2d4c 77f82829 00000000 0085fe0c 00000001 nt!KiTrap0E+0xc3
0085fe58 00000000 00000000 00000000 00000000 +0x77f82829

Thanks,

Rini


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

Hi Tony:

Thanks for the information. Actually I had followed the same info when I
was debugging yesterday. The file for which the read had been sent is a
pagefile. So, it is a paging IO. But, our driver had a problem in
ObOpenObjectByPointer(). Is there some way to find if the accesstoken is
valid or not? This problem happened when the overlying service died and
was restarted.

Regards,

Rini

Rini,

Assuming that this is the access token that is being touched, it isn’t in
memory (since the in-page operation failed) so there would be no way to
validate it.

If it IS in memory you can use “!token” to analyze it in the debugger.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@yahoo.com [mailto:xxxxx@yahoo.com]
Sent: Thursday, March 21, 2002 1:22 PM
To: File Systems Developers
Subject: [ntfsd] Re: Validity of access token and Bug Check 7A

Hi Tony:

Thanks for the information. Actually I had followed the same info when I
was debugging yesterday. The file for which the read had been sent is a
pagefile. So, it is a paging IO. But, our driver had a problem in
ObOpenObjectByPointer(). Is there some way to find if the accesstoken is
valid or not? This problem happened when the overlying service died and
was restarted.

Regards,

Rini


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

> pagefile. So, it is a paging IO. But, our driver had a problem in

ObOpenObjectByPointer(). Is there some way to find if the accesstoken is
valid or not?

Doing ACL checks in paging IO path is a bit strange idea. Usually, CREATE path is the only place where ACL checks are made.

Max