我的设置：具有windbg的Windows 10和目标计算机是Windows 7 N SP1。我正在通过com调试（我知道它很慢；）。

所以我得到!process的进程列表，其中一个活动进程是Internet Explorer： >
之后，我想看看进程以哪种模式运行。因此，我在U / S标志处查看了PDE的内容。 

kd>!process 0 0

>PROCESS fffffa8001a3db30
>SessionId: 2  Cid: 07e0    Peb: 7efdf000  ParentCid: 0a90
>DirBase: 2cc0a000  ObjectTable: fffff8a002007620  HandleCount: 561.
>
>Image: iexplore.exe


usermode / kernelmode标志设置为K。这表示iexplorer.exe在内核模式下运行。为什么？我认为这些应用程序正在用户模式下运行。

评论

您正在混淆。每个用户模式进程的99％线程最终都将转换为内核模式，以进行文件I / O，套接字，内存管理等等。请注意，线程的调用堆栈从用户到内核模式的过渡是一个明确定义的（安全性）边界。您不能直接调用任何kernelmode函数。
@LievenKeersmaekers请尽量避免在评论中发布答案，最好发布实际答案。
@IgorSkochinsky-不好意思，它的充实程度不足以作为答案，而且我在该主题上没有足够的专业知识来撰写完整的答案，但我一定会注意！

#1 楼

问题中列出的内容不会告诉您流程正在执行的模式，而思考流程有几处错误。

!pte的帮助文档指定该命令使用虚拟地址并显示有关该地址的PTE和PDE信息。此命令的输出有点不直观，因为实际上PTE / PDE条目是物理地址，但是Windows也会将它们映射到内核虚拟内核地址。

在您的输出中，特别是您所使用的虚拟地址正在分析是VA fffff6fd4000d000。输出显示的是此虚拟地址的PXE条目位于物理地址4000000（这由pfn条目给出，下部被标记等屏蔽），并映射到虚拟地址FFFFF6FB7DBEDFA8。

所以下一部分就是为什么输出显示页面是内核模式的原因。根据您正在执行的操作，从！address获得的地址为fffffa8001a3db30。在无需过多介绍内核内部细节的情况下，该地址是EPROCESS对象的虚拟地址，它是用于管理系统上进程的内核数据结构。此外，内核分配的每个对象都有一个标头，该标头被系统用来进行引用计数和其他一些管理功能。

您可以使用dt命令在windbg中查看此标头结构：在x64上，您会注意到此结构的大小为0x30字节。因此，实际EPROCESS的地址为dt _OBJECT_HEADER，但是分配的基础包括标头为fffffa8001a3db30。

因此，基本上，运行fffffa8001a3db00命令时的工作是分析内核EPROCESS对象的页表条目，但是正如我在上一段中所说的，这只是内核分配并用于管理系统资源的结构，因此此地址始终将是内核模式地址。

要执行您实际想要的操作，请使用以下命令： br /> !pte-这使您
进入Internet Explorer的进程上下文，这基本上意味着
windbg访问的所有用户模式内容（虚拟内存和句柄）
对于该进程有效

.process /p /r <iexplore.exe address from !process>或!dml_proc <iexplorer address from !process>-此
为您提供有关该进程中正在运行的线程的信息

如果使用！dml_proc，则可以从此处单击链接
获取线程堆栈，或！process只会为您转储所有线程

现在，如果您按照上面的方法，您将获得每个线程的堆栈跟踪。从那里可以看到它基于所在模块的执行位置。特别是，如果在调用堆栈上看到!process <iexploer address from !process，则意味着该线程已转换为内核模式并且正在执行某些操作。

但是话虽这么说，我仍然不确定要实现什么目标，因为在您的帖子中，有一篇评论提到所有线程都将一直转换到内核模式，因为基本上系统上发生的所有事情都是在内核模式下发生的。 br />

#2 楼

在pte命令上，使用一个地址，从那里获得该地址FFFFF6FB7EA00068 <<<<<

如果它是虚拟地址，它确实属于活动进程上下文吗？ br />您是否在iexplore.exe的进程上下文中？ (did you do .process /p /r EPROC_ADDR )

只做.process / p / r仅更改windbg中的显示，并且实际的基础流程可能不等于当前流程上下文

是否检查进程上下文DirectoryTableBase（DirBase）和寄存器cr3是否匹配？

如果它们不匹配，您可能正在查看一些属于虚假的地址，该地址属于其他进程上下文，这些地址可能具有相同的虚拟地址

，如果它不匹配，您可能会发现需要执行.process / i并使用g或f5执行目标

，这将使windbg侵入性地调试基础进程，并且当它重新启动时
几秒钟后您感兴趣的进程（
将设置为活动进程上下文，并且将针对活动进程上下文解码页表条目（寄存器cr3和@ $ proc-> Pcb.DirectoryTableBase将匹配并显示相同的DirBase）

仅当您真正确定自己具有活动的流程上下文时，您的问题才可以发出可重复的查询

示例

目标和主机都是win7 sp1 32位（目标是vm）
windbg版本是发布之日的最新rtm。 br /> 
Microsoft (R) Windows Debugger Version 10.0.16299.15 X86


检查iexplore.exe流程实例

checking current cr3
kd> r cr3
cr3=00185000


命令以查看iexplore模块是否可用

kd> !process 0 0 iexplore.exe
PROCESS 841f3c08  SessionId: 1  Cid: 059c    Peb: 7ffdf000  ParentCid: 0774
    DirBase: 096de000  ObjectTable: 92aed4d0  HandleCount: 419.
    Image: iexplore.exe

PROCESS 841ce5d8  SessionId: 1  Cid: 0784    Peb: 7ffdf000  ParentCid: 059c
    DirBase: 0db73000  ObjectTable: 8b221ba0  HandleCount: 350.
    Image: iexplore.exe


没有windbg不在正确的过程上下文中
让它进入正确的过程上下文中
请记住，这只是显示而不是目标状态
请参阅.cache（windbg从其缓存的数据刷新显示
）

您会注意到模块iexplore.exe现在可以检查了

kd> lm m iexp*
Browse full module list
start    end        module name

Unable to enumerate user-mode unloaded modules, Win32 error 0n30

我们不在活动进程上下文中（寄存器cr3和DirBase不匹配）
进入活动进程上下文windbg应该
侵入性地调试目标进程
我们执行.process / i 
kd> .process /p /r 841ce5d8
Implicit process is now 841ce5d8
.cache forcedecodeuser done
Loading User Symbols

kd> lm m iexp*
Browse full module list
start    end        module name
00af0000 00b96000   iexplore   (deferred)             
kd> x iexplore!wWinMain
00af12a3          iexplore!wWinMain (<no parameter info>)


让进程环境处于活动状态时，请windbg侵入性地调试iexplore.exe并中断


kd> !pte iexplore!wWinMain
                 VA 00af12a3
PDE at C0300008         PTE at C0002BC4
contains 00000000
not valid


kd> r cr3
cr3=00185000

kd> ?? @$proc->Pcb.DirectoryTableBase
unsigned long 0xdb73000


现在您可以同时看到寄存器上下文和Dirbase匹配项了。下面

kd> .process /i /p /r /P 841ce5d8
You need to continue execution (press 'g' <enter>) for the context
to be switched. When the debugger breaks in again, you will be in
the new process context.
kd> g
Break instruction exception - code 80000003 (first chance)
nt!RtlpBreakWithStatusInstruction:
8289dd00 cc              int     3


物理地址内容的转储

kd> r cr3
cr3=0db73000

kd> ?? @$proc->Pcb.DirectoryTableBase
unsigned long 0xdb73000

kd> !pte iexplore!wWinMain
                 VA 00af12a3
PDE at C0300008         PTE at C0002BC4
contains 0DD71867       contains 07B5F005
pfn dd71  ---DA--UWEV   pfn 7b5f  -------UREV

pte enties are valid now


虚拟地址内容与物理页面内容匹配
，但让我们寻找一个唯一的字符串并重新配置m 

kd> !pte iexplore!wWinMain
                 VA 00af12a3
PDE at C0300008         PTE at C0002BC4
contains 0DD71867       contains 07B5F005
pfn dd71  ---DA--UWEV   pfn 7b5f  -------UREV

kd> db iexplore!wWinMain l 20
00af12a3  8b ff 55 8b ec 81 ec 30-01 00 00 a1 50 c0 af 00  ..U....0....P...
00af12b3  33 c5 89 45 fc 53 56 57-be 88 c5 af 00 56 e8 cb  3..E.SVW.....V..


kd> $$ from the !pte above we know pfn is at 7b5f 
kd> $$ we can confirm if this is the right physical page with either 
kd> $$ !vtop 0 va or simply adding the last 3 bytes of our va to the pfn 
kd> $$and dump the physical page