[SOLVED] !pte = Levels not implemented for this platform

xrobwx71

xrobwx71

Administrator
Staff member
Joined
Sep 27, 2019
Posts
2,818
Location
Panama City Beach, FL
@x BlueRobot

I experienced a BSOD and proceeded to try and debug using your blog post here.

From your blog:
Now, let’s dump the page table entry for the memory address which caused the page fault by using the !pte extension command.

7: kd> !pte ffffcc0150939000

When I run the !pte (my Arg1 memory reference) The output is- Levels not implemented for this platform.

What causes this?
 

Attachments

xrobwx71 said:
What causes this?
Click to expand...
It means that the address you used didn't have a page table entry (PTE) associated to it. WinDbg basically takes that address and then calculates the associated PTE, if it can't find one, then it throws that error message. Your crashes are very consistent with each other which certainly suggests a software issue.

I found this SID in one of your dump files (!dpx), it might be worth having a look at what this could possibly belong to?

Code: 
S-1-5-80-123231216-2592883651-3715271367-3753151631-4175906628

Rich (BB code): 
10: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffffe180`30b3e138 fffff803`6c08c83a     nt!KeBugCheckEx
01 ffffe180`30b3e140 fffff803`6be6211c     nt!MiSystemFault+0x1fd42a
02 ffffe180`30b3e240 fffff803`6c027929     nt!MmAccessFault+0x29c
03 ffffe180`30b3e360 fffff803`6beb13ee     nt!KiPageFault+0x369
04 ffffe180`30b3e4f0 fffff803`6beb0e88     nt!RtlpUnwindPrologue+0x19e
05 ffffe180`30b3e5c0 fffff803`6beb0d69     nt!RtlpxVirtualUnwind+0x108
06 ffffe180`30b3e680 fffff803`6c30c645     nt!RtlVirtualUnwind2+0x89
07 ffffe180`30b3e710 fffff803`6c020c3d     nt!PspGetSetContextInternal+0x315
08 ffffe180`30b3eda0 fffff803`6c371db7     nt!PspGetSetContextSpecialApc+0x6d
09 ffffe180`30b3eeb0 fffff803`6c2e1e6d     nt!PspSetContextThreadInternal+0x127
0a ffffe180`30b3f0c0 fffff803`6c2e242c     nt!WbSetTrapFrame+0xb9
0b ffffe180`30b3f100 fffff803`6c2e12ca     nt!WbValidateHeapExecuteCallArguments+0x278
0c ffffe180`30b3f150 fffff803`6c2deaac     nt!WbDispatchOperation+0x10a
0d ffffe180`30b3f1b0 fffff803`6c2de72d     nt!ExpQuerySystemInformation+0x31c
0e ffffe180`30b3f9e0 fffff803`6c02bbe5     nt!NtQuerySystemInformation+0x5d
0f ffffe180`30b3fa20 0000029d`8a35ad58     nt!KiSystemServiceCopyEnd+0x25

It seems those Wb! calls are related to Microsoft's Warbird obfuscation software and is commonly used with DRM which would explain why you're consistently crashing in the sppsvc (Software Protection) service.

More information: Example of Windows Warbird Encryption/Decryption
 
Just for information, the error with the !pte command is completely unrelated with finding or not finding the associated PTE. The issue lies with WinDBG and has been known for a while know.

The error is caused by the kd extension checking the Paging Levels supported by the OS before trying to calculate the PTE.

Code: 
0: kd> dt nt!_MI_VISIBLE_STATE nt!MiState+0x4440
   +0x000 SessionWsList    : _LIST_ENTRY [ 0x00000000`00000000 - 0x00000000`00000000 ]
   +0x010 SessionIdBitmap  : 0xb6121da4`88feeab9 _RTL_BITMAP
   +0x018 PagedPoolInfo    : _MM_PAGED_POOL_INFO
   +0x030 MaximumNonPagedPoolInPages : 0
   +0x038 SizeOfPagedPoolInPages : 0
   +0x040 SystemPteInfo    : _MI_SYSTEM_PTE_TYPE
   +0x098 NonPagedPoolCommit : 0x00000009`00000002
   +0x0a0 SmallNonPagedPtesCommit : 0
   +0x0a8 BootCommit       : 0
   +0x0b0 MdlPagesAllocated : 0x93e00
   +0x0b8 ContiguousPagesAllocated : 0x1fa40
   +0x0c0 SystemPageTableCommit : 0x1a600
   +0x0c8 ProcessCommit    : 0xffffa7e0`00037310
   +0x0d0 DriverCommit     : 0n-295825
   +0x0d4 PagingLevels     : 0xff ''                <------------------- THIS HAS TO BE 0x4 FOR !pte to WORK
   +0x0d8 PfnDatabaseCommit : 0x9800
   +0x100 SystemWs         : [6] _MMSUPPORT_FULL
   +0x880 SystemCacheShared : _MMSUPPORT_SHARED
   +0x900 AggregateSystemWs : [1] _MMSUPPORT_AGGREGATION
   +0x920 MapCacheFailures : 0
   +0x928 PagefileHashPages : 0
   +0x930 PteHeader        : _SYSPTES_HEADER
   +0xa48 SystemVaTypeCount : [18] 0xfffff800`21c69fc0
   +0xad8 SystemVaType     : [256]  ""
   +0xbd8 SystemVaRegions  : [15] _MI_SYSTEM_VA_ASSIGNMENT

As observable, on certain versions of Windows this value is 0xff. Not 100% sure what causes this.

Check on your system the value of PagingLevels issuing the following command:
db nt!MiState+0x4440+0xd4 L1

If the result is different from from 0x4, a workaround is to set the value to 0x04 and reload the kdexts extension (cause it might have cached it).

Code: 
// Force it to 0x4
ed nt!MiState+0x4440+0xd4 0x4

// As this value can be cached by the kd extension, just reload it
.unload kdexts
.load kdexts

Just leaving this here in case anyone is searching for a fast workaround to this issue.
 
@xrobwx71 Have you tried a clean boot or have you managed to find a consistent pattern to the crashes? I don't think this is going to be anything on the kernel side.
 
I have not.

No pattern at all. I haven't had a crash since. The one change I made prior to the BSOD was installing a program called Wallpaper Engine. The wallpapers are short videos played in a loop. I think it was a particular wallpaper/screensaver I chose as since I have changed it, no more crashes. I haven't had the time to test this theory.

Thank you for the help.

edit: Come to think of it, the screensavers may be the cause of the DRM issues you mentioned above.
 
Strange, at least you haven't had any issues since then, you might just want to keep an eye on and see if it crashes again.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top