Share via

Windbg !pte command: Levels not implemented for this platform

Richard Lyman 11 Reputation points
2022-09-16T05:49:50.31+00:00

Debbugging an amd64 vm. !pte command randomly stops working and says "Levels not implemented for this platform". Also it does so instantly, without even stoping to think about it. Sometimes toggling debug in bcdedit in the vm fixes it, sometimes it doesn't. You all need to fix this shit

Windows API - Win32
Windows API - Win32
A core set of Windows application programming interfaces (APIs) for desktop and server applications. Previously known as Win32 API.
2,523 questions

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. wkmckenzie 0 Reputation points
    2023-09-11T16:24:46.8133333+00:00

    Hey Microsoft, I am having the same issue.

    I am connecting WinDbg version 10.0.22621.1778 as a remote kernel debugger using net debugging. The target is a Windows 10 22H2 (10.0.19045.3208) VMWare Workstation VM.

    I tried this:

    0: kd> x nt!PsNtosImageBase
    fffff801554fc4a0 nt!PsNtosImageBase = <no type information> 0:kd> !pte fffff801554fc4a0
    Levels not implemented on this platform

    What gives with "Levels not implemented on this platform" ??

  2. Gary Nebbett 5,856 Reputation points
    2023-09-12T18:29:36.4633333+00:00

    Hello All,

    This may well be a known issue that has not been addressed (for four years now).

    Andrey Bazhan reported the problem here: https://github.com/microsoftfeedback/WinDbg-Feedback/issues/8

    Someone, seemingly from Microsoft, responded: "The right people on the kernel side are aware of this, but I don't have an ETA for a change."

    The problem seems to be with the PDB description of the _MI_SYSTEM_INFORMATION structure (this structure is mentioned in the Windows Internals book).

    The !pte command tries to read and use the contents of the Vs.PagingLevels member but, since its PDB calculated offset is wrong, a different/incorrect value is used.

    The difference between the calculated and actual offsets is often 0x40 (varies from build to build). If the difference in a particular build is 0x40, then reads of "MiState.Vs.PagingLevels" actually read the 5th byte of the pointer "MiState.Vs.SystemPteInfo.CachedPtes" (e.g. 0xffff9580`000160c8); if the actual PagingLevels value is 4 and this byte has a value of 4 or 0 (implies use default value of 4) then the !pte command works. This probably explains why rebooting the system (changing the pointer value) sometimes helps.

    Gary

    0 comments
  3. I.A. Alday 0 Reputation points
    2023-11-21T16:34:03.5866667+00:00

    Hi everybody. Is this problem already fixed in any version? In the last W10 update i have downloaded today (Nov-20th-2023) the problem is still happening. I can patch the symbols and get the correct behavior but it is pretty annoying.

    0 comments