windows是微内核吗_windows内核问题定位-教育考试-生活指南—

课程：

1、win10系统下怎样查看计算机内核动态
2、内核丢失或损坏，windows无法加载，怎么办？
3、系统故障：WindowsXP系统内核问题紧急求助！！！NSIS Error
4、如何获取Windows 系统的内核变量
5、电脑开机后windows未能启动，显示内核丢失或损坏，怎么处理？
6、关于WINDOWS内核的相关问题，以及进程与线程问题。复制粘贴的，进来科普的就不要来了！一个问题追加100

win10系统下怎样查看计算机内核动态

不少 windows10系统用户在使用火绒剑检查计算机状态时，都遇到了系统运行不正常的情况，可是通过“系统”、”进程“和“启动项”模块都无法检测出异常的情况。其实，该问题可能是系统内核遭到篡改导致的。那么，如何查看计算机内核状态呢？下面，小编就分享使用火绒剑查看计算机内核动态的具体方法。

具体如下:

1、打开火绒剑，转到“内核”模块，软件将会自动列出当前系统内所有已经注册的驱动文件（即设备树），提供这些项目的名称、安全状态、路径、地址、公司名、描述等信息；

2、用户单击选中任意一个可识别的驱动之后，软件将会自动在屏幕下方显示出该驱动的模块、路径、描述版本、说明、公司等数据，以供用户参考；

3、如果用户需要对当前已经列出的所有驱动进行检查，可以尝试点击屏幕左上角的“展开/收起全部”按钮，手动列出所有的驱动清单，查看所有驱动数据；

4、选中任意一个驱动之后，用户也可以尝试点击界面左上方的“定位文件”按钮，转到“文件”模块查看当前选中驱动的详细信息；

5、如果用户认为某一模块存在不正常状态，也可以尝试选中之后，点击“属性”按钮，查看该驱动在Windows资源管理器中的属性描述；

6、由于软件提供了对于某一些驱动的安全检查功能，遇到未知的驱动，且不带有数字签名的，软件将会识别为“未知文件”，如果文件本身不带有说明，软件不会显示任何相关数据，此时可以进行针对性检查。

windows是微内核吗_windows内核问题定位

内核丢失或损坏，windows无法加载，怎么办？

你好。可用系统光盘或者U盘重装系统。

用U盘安装系统：

1、开机时，屏幕的右下角有提示，现在的新主板不需要进入BIOS进行设置计算机从USB启动了，

如技嘉主板开机按F12就可以选择从USB启动。

2、如果是老式计算机，我们开机按Del键或其它键（视主板类型和计算机型号而确定按什么键）

进入BIOS - boot ... #1，回车，设置从USB启动，再按F10键保存，在弹出的提示框中输入：

Y（是），回车，计算机重启进入USB安装系统。

3、我们用键盘上的方向键选择：运行老毛桃Win8PE防蓝屏版（新电脑）；

进入U盘安装系统窗口后，点击：老毛桃一键装机图标，默认：还原分区，选择要安装的系统文

件和安装系统的磁盘（单系统安装默认安装到C盘），点击：确定；在打开的窗口的添加引导、

无人值守、完成重启、文件校验等复选框打勾，再点击确定，开始安装系统。

请参考《百度经验》

《U启动盘制作及用USB PE一键安装系统（一）》图文并茂

系统故障：WindowsXP系统内核问题紧急求助！！！NSIS Error

马上去找了个内存检测软件，memtest，下载地址：，下载后一用，一检测，果然几十个内存Error！

关机，打开主机机箱发现里面有两条内存，先换个位置，进去测试，发现报错的几率小了，但是装大软件还是会失败，可以断定是其中一条内存有问题了，拔掉一根再检测，通过，在没有报错，问题解决！

如何获取Windows 系统的内核变量

PsLoadedModuleList等重要内核变量并未被ntoskrnl.exe导出，也没有公开的函

数可以获取。而这些内核变量对于Rootkit、Anti-Rootkit 以及内核溢出的利用等都

是至关重要的。

下面我们以PsLoadedModuleList、PsActiveProcessHead 等为例，介绍得到这些

变量的方法。

对于Windows NT 4.0和Windows 2000，尚没有“温柔”的办法可以获取这些变量，

比较理想的办法也就是特征代码搜索，这种方法虽然暴力，但通常都很有效，一般也

不会出问题；对于Windows XP和Windows 2003，我们找到了一些更加优雅的选择。

下面首先介绍特征代码搜索的方法。

[DWORD KernelBase]

要进行特征代码搜索，首先要定位ntoskrnl.exe在内核的加载地址KernelBase。

这个地址可以通过ZwQuerySystemInformation Class 10的SystemModuleInformation

来得到。参考资源[1]中给出了相关代码。事实上，KernelBase 这个值对同一操作系

统来说非常固定，可以作为常量来用：

Windows NT： 0x80100000

Windows 2000：0x80400000

Windows XP： 0x804d1000

Windows 2003: 0x804e0000

Windows NT 4.0 ntoskrnl.exe 的OptionalHeader-ImageBase = 0x80100000，

ntldr 也会按照这个值来加载内核，但是从Windows 2000开始就不是这样了。可能基

于这个历史原因，各系统的*(DWORD *)PsNtosImageBase始终初始化为0x80100000。

另外，内核变量PsNtosImageBase、KdpNtosImageBase等也指向KernelBase：

KernelBase = *(DWORD *)PsNtosImageBase

KernelBase = *(DWORD *)KdpNtosImageBase

[LIST_ENTRY PsLoadedModuleList]

PsLoadedModuleList这个全局变量指向一个保存着所加载驱动信息的双向链表。

通过它可以枚举系统中所有的驱动模块。

虽然很多内核函数都用到了PsLoadedModuleList，但是大部分并没有被导出，而

从基址开始搜会很花时间。对于Windows 2000来说，从下面这个地方入手是个好主意：

nt!MmGetSystemRoutineAddress+0x66:

804f0ed0 8b35f0e84680 mov esi,[nt!PsLoadedModuleList (8046e8f0)]

804f0ed6 81fef0e84680 cmp esi,0x8046e8f0

流程如下：

1、ImageBase = LoadLibraryA("ntoskrnl.exe")

2、GetProcAddress(ImageBase,"MmGetSystemRoutineAddress")

3、搜索特征代码：

*(WORD *)(MmGetSystemRoutineAddress + i) = 0x358b \

*(WORD *)(MmGetSystemRoutineAddress + i + 6) = 0xfe81

*(DWORD *)(MmGetSystemRoutineAddress + i + 2) == \

*(DWORD *)(MmGetSystemRoutineAddress + i + 8)

4、定位内核中的地址：

PsLoadedModuleList = \

*(DWORD *)(MmGetSystemRoutineAddress + i + 2) + (KernelBase - ImageBase)

从SP0到SP4，i值并不相同，但是肯定不大于0x100。

对Windows NT来说，就没这么好运气了，没有理想的可用于定位的API，只能从头

开始搜索。下面这段代码至少对SP1~SP6a的来说都具有很好的稳定性和唯一性：

801CEB1C: 8B 4D 08 mov ecx,dword ptr [ebp+8]

801CEB1F: 89 01 mov dword ptr [ecx],eax

801CEB21: 8B 45 0C mov eax,dword ptr [ebp+0Ch]

801CEB24: 89 10 mov dword ptr [eax],edx

801CEB26: 8B 36 mov esi,dword ptr [esi]

801CEB28: 81 FE 70 0B 15 80 cmp esi,80150B70h //PsLoadedModuleList

如果是用驱动做这件事情，就不必暴力搜索了，fuzen_op（fuzen_op@yahoo.com)

在FU_Rootkit2.0（参考资源[2]）中使用了一段比较巧妙的代码：

DWORD FindPsLoadedModuleList (IN PDRIVER_OBJECT DriverObject)

{

PMODULE_ENTRY pm_current;

if (DriverObject == NULL)

return 0;

pm_current = *((PMODULE_ENTRY*)((DWORD)DriverObject + 0x14));

if (pm_current == NULL)

return 0;

gul_PsLoadedModuleList = pm_current;

while ((PMODULE_ENTRY)pm_current-le_mod.Flink != gul_PsLoadedModuleList)

{

if ((pm_current-unk1 == 0x00000000) \

(pm_current-driver_Path.Length == 0))

{

return (DWORD) pm_current;

}

pm_current = (MODULE_ENTRY*)pm_current-le_mod.Flink;

}

return 0;

}

[LIST_ENTRY PsActiveProcessHead]

理论上PsActiveProcessHead 也可以用搜索代码的方法来取，但是还有更简单的

方法。

ntoskrnl.exe导出的PsInitialSystemProcess 是一个PEPROCESS，指向system进

程的EPROCESS。这个EPROCESS的结构成员EPROCESS.ActiveProcessLinks.Blink 就是

PsActiveProcessHead：

kd dt _EPROCESS ActiveProcessLinks.Blink poi(PsInitialSystemProcess)

+0x0a0 ActiveProcessLinks : [ 0x81356900 - 0x8046e728 ]

+0x004 Blink : 0x8046e728 [ 0x81a2fb00 - 0xff5a4ce0 ]

kd ? PsActiveProcessHead

Evaluate expression: -2142836952 = 8046e728

EPROCESS这个结构在不同的操作系统上各不相同，需要分别对待。

[struct _KDDEBUGGER_DATA64 KdDebuggerDataBlock]

Windows 2000 开始，系统引入了变量KdDebuggerDataBlock。其中包含了大量的

内核变量。如果能够获取到的话，可以解决许多问题。遗憾的是，Windows NT上没有

这个变量。WinDBG SDK的wdbgexts.h中包含了它的结构：

typedef struct _KDDEBUGGER_DATA64

因为比较长，这里就不引用了。

从对5.0.2195.6902版本ntoskrnl.exe 的逆向工程结果来看，只有两个函数使用

了该变量，并且，两个函数都未导出，且代码前后没有明显特征，无法靠直接搜索代

码来获取。

但是，我们发现，ntoskrnl.exe导出了KdEnableDebugger，KdEnableDebugger会

调用KdInitSystem，而KdInitSystem 中引用了KdDebuggerDataBlock：

n 100

Windows 2000：

KdEnableDebugger + n:

6A 00 push 0

C6 05 28 41 48 00 01 mov _PoHiberInProgress, 1

E8 1C DC 10 00 call _KdInitSystem@8 ; KdInitSystem(x,x)

KdInitSystem + n:

68 70 02 00 00 push 270h // sizeof(KdDebuggerDataBlock)

B9 50 D1 54 00 mov ecx, offset _KdpDebuggerDataListHead

68 D8 FA 46 00 push offset KdDebuggerDataBlock

8B 40 18 mov eax, [eax+18h]

68 4B 44 42 47 push 4742444Bh // "KDBG"，可以用作搜索的定位标志

A3 3C D1 54 00 mov ds:_KdpNtosImageBase, eax

89 0D 54 D1 54 00 mov ds:dword_54D154, ecx

89 0D 50 D1 54 00 mov ds:_KdpDebuggerDataListHead, ecx

Windows XP

KdEnableDebugger + n:

6A 00 push 0

C6 05 8C 98 47 00 01 mov _PoHiberInProgress, 1

E8 2B 17 13 00 call _KdInitSystem@8 ; KdInitSystem(x,x)

KdInitSystem + n:

68 90 02 00 00 push 290h

68 E0 9D 46 00 push offset KdDebuggerDataBlock

BE 74 96 59 00 mov esi, offset _KdpDebuggerDataListHead

68 4B 44 42 47 push 4742444Bh

89 35 78 96 59 00 mov ds:dword_599678, esi

89 35 74 96 59 00 mov ds:_KdpDebuggerDataListHead, esi

Windows 2003

KdEnableDebugger + n:

56 push esi

C6 05 0C 08 49 00 01 mov PoHiberInProgres, 1

E8 CB AD 15 00 call _KdInitSystem@8 ; KdInitSystem(x,x)

KdInitSystem + n:

68 18 03 00 00 push 318h

68 D0 A3 47 00 push offset KdDebuggerDataBlock

BE 18 10 5D 00 mov esi, offset _KdpDebuggerDataListHead

68 4B 44 42 47 push 4742444Bh

89 35 1C 10 5D 00 mov ds:dword_5D101C, esi

89 35 18 10 5D 00 mov ds:_KdpDebuggerDataListHead, esi

可以看出，上面代码特征的唯一性很好。用于搜索是没有问题的。我在上面同时

列出了三个系统的代码，仅仅只是为了比较，事实上，对Windows XP和Windows 2003

是完全没有必要采取如此暴力手段的。

电脑开机后windows未能启动，显示内核丢失或损坏，怎么处理？

这种情况可以使用U盘pe工具，可以尝试修复。

进入PE系统的界面，接着点击桌面上的WINDOWS启动引导修复。

双击打开后出现如下图：

按1，选择自动修复，等待自动修复完成。

关于WINDOWS内核的相关问题，以及进程与线程问题。复制粘贴的，进来科普的就不要来了！一个问题追加100

1.根据个人见解，不按进程分时间片，只按线程分片，并且在多核机器中，单个进程中的多个线程也有可能分到不同的核心中的某个时间片去。因为进程只是一种统筹多个线程让其之间可以协调/资源共享的机制，本质上在运行的其实是线程。

2.到了内核就应该不是线程和进程的概念了，因为两者是不同层次的。应该是进程在内核的支持下跑，正是内核的管理机制抽象出了进程和线程的概念。

这个问题就像是你开了一部虚拟机，然后问虚拟机在现实系统中所在的进程与虚拟系统中的进程之间的关系一样。

3.硬件抽象层对真实物理硬件的操作是靠I/O端口，物理上，硬件接在总线上可轮流使用总线，然后硬件可以在自己的时间片里面触发中断，这样CPU就收到通知并跳转到相应的程序段来处理这个中断，这段个程序段负责自动化地完成与硬件打交道的工作，然后规范化地向上层的程序反馈/接收，由上层程序决定下一步动作。而处理中断的这段程序就应该位于抽象层，它让上层程序只需要发送处理命令和接收到处理结果，而不用详细了解底层硬件是怎么运作的。所以个人认为操作方式在软上本质上是处理中断，在硬件上是通过总线传输数据。

已经毕业接近一年，手边没有操作系统的书，全凭记忆，可能会有不正确的地方，望指正。