当错误报的是0x135时,用windbg分析dump文件实在是看不出什么东西,这里还是放个大概,供大家比对参考:
STACK_TEXT:
807ec12c 840eb654 00000135 c0000005 807ec270 nt!KeBugCheckEx+0x1e
807ec144 840eaa14 83ec6494 00000000 807ec8b0 nt!CmpFatalFilter+0x17
807ec8b0 84080722 0000000e 807ec908 00000001 nt!CmpCallCallBacks+0x16d
807ec91c 8406f591 a8ff5668 a8ff5668 a8ff5650
nt!CmpDeleteKeyObject+0x81807ec934 83ec4d60 00000000 85fdd4c0 a8ff5650
nt!ObpRemoveObjectRoutine+0x59807ec948 83ec4cd0 a8ff5668 84092308 87801b28
nt!ObfDereferenceObjectWithTag+0x88807ec950 84092308 87801b28 85fdd4c0 0000086c
nt!ObfDereferenceObject+0xd807ec990 8409202e 87801b28 a99850d8 85fd1020
nt!ObpCloseHandleTableEntry+0x21d807ec9c0 8408e965 85fd1020 00000000 00000000 nt!ObpCloseHandle+0x7f
807ec9d8 8401065a 8000086c 00000000 00000000 nt!ObCloseHandle+0x40
807ecbbc 84013d98 00000001 00000000 807ecbe4 nt!IopLoadDriver+0xb61
807ecc00 83ec9aab ac9adbd0 00000000 85fdd4c0
nt!IopLoadUnloadDriver+0x70807ecc50 84055f5e 00000001 36f5aa8c 00000000 nt!ExpWorkerThread+0x10d
807ecc90 83efd219 83ec999e 00000001 00000000
nt!PspSystemThreadStartup+0x9e00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
THREAD_SHA1_HASH_MOD_FUNC: 049e447e55a7b64e8d7f3231653085e63a317e65THREAD_SHA1_HASH_MOD_FUNC_OFFSET:
a997c0d526fdb0f4723fb306ecfdf66411f77893THREAD_SHA1_HASH_MOD: 38bc5fec3f0409c265cf5c87da6f8f8859d0711c
FOLLOWUP_IP:
nt!CmpFatalFilter+17
840eb654 cc int 3
FAULT_INSTR_CODE: 909090cc
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt!CmpFatalFilter+17
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrpamp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4ce78a09
IMAGE_VERSION: 6.1.7601.17514
STACK_COMMAND: .thread ; .cxr ; kb
FAILURE_BUCKET_ID: 0x135_VRF_nt!CmpFatalFilter+17
BUCKET_ID: 0x135_VRF_nt!CmpFatalFilter+17
PRIMARY_PROBLEM_CLASS: 0x135_VRF_nt!CmpFatalFilter+17
TARGET_TIME: 2019-09-23T08:11:47.000Z
OSBUILD: 7601
OSSERVICEPACK: 1000
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 272
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x86
OSNAME: Windows 7
OSEDITION: Windows 7 WinNt (Service Pack 1) TerminalServer
SingleUserTSOS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2010-11-20 16:42:49
BUILDDATESTAMP_STR: 101119-1850
BUILDLAB_STR: win7sp1_rtm
BUILDOSVER_STR: 6.1.7601.17514.x86fre.win7sp1_rtm.101119-1850
ANALYSIS_SESSION_ELAPSED_TIME: 2dc
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x135_vrf_nt!cmpfatalfilter+17
FAILURE_ID_HASH: {1cf614a7-193c-d67a-fc81-ffe957d678c0}
我查了很多论坛和Windows官方资料,对于0x135的错误解释大多跟驱动没什么关系,都是说文件丢失什么的,在论坛发帖也是没什么回应。当时也不太会用windbg分析,对于0x135报错实在是无能为力。所以我的个人认为,在使用Verifier检测驱动得到0x135报错之后,使劲分析0x135可能很难,如果你恰好跟我一样有交叉报错或者可以定位到具体语句,一定要从这些方面入手。
但是我这此的情况是0x135偶尔会和0xD6交叉报错,然后分析0xD6的dump文件会定位到一段代码。
PCHAR pIo = (PCHAR)pIoBuffer;
const size_t cSize = strlen(pIo);
PCHAR pIoC = (PCHAR)ExAllocatePoolWithTag(NonPagedPool, sizeof(char)*(cSize + 1), REGISTRY_POOL_TAG);
RtlStringCbCopyA(pIoC, cSize * sizeof(char), pIo + sizeof(char));
int find = KStrFind(pIoC, '\\');/*错误代码定位*/
进入KStrFind函数,发现定位到了一句定义赋值语句
int KStrFind(PCHAR string, const char sh)
{
PCHAR test = string;
size_t len = strlen(test);/*错误语句*/
size_t i = 0;
for (i = 0; i < len; i++)
{
//省略
}
我尝试过几个修改的办法,最后任何这条语句本身应该是不会出现问题的。
然后我将相关的几个参数包括pIo,pIoC,cSize,len等变量都进行了输出,发现输出中有pIo为空的情况,而我又在语句
RtlStringCbCopyA(pIoC, cSize * sizeof(char), pIo + sizeof(char));
引用了pIo指针后sizeof(char)字节的内容,因此导致pIoC本身的异常和传入参数的异常。
最后在对pIoC前加入了pIo不为空的判断,至此0x135和0xD6的蓝屏问题都得到了解决。