Windows更新1903年导致文件系统驱动程序崩溃

Question

我有一个严重的问题窗口文件系统KMDF驱动程序。此问题发生在Windows 10 ver1903更新(可能是最新更新)之后。在任何windows 10版本更新之前，驱动程序运行平稳。当驱动程序开始运行带有"WDF_VIOLATION“错误的系统CARSH (蓝屏)时。

我用“”工具打开了系统转储文件，发现了这个错误日志：

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 0000000000000005, A framework object handle of the incorrect type was passed to
    a framework object method.
Arg2: 0000000000000000, The handle value passed in.
Arg3: 0000000000001023, Reserved.
Arg4: ffffd808fc533e00, Reserved.

Debugging Details:
------------------


KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.Sec
    Value: 7

    Key  : Analysis.Elapsed.Sec
    Value: 23

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 72


PROCESSES_ANALYSIS: 1

SERVICE_ANALYSIS: 1

STACKHASH_ANALYSIS: 1

TIMELINE_ANALYSIS: 1


DUMP_CLASS: 1

DUMP_QUALIFIER: 401

BUILD_VERSION_STRING:  18362.1.amd64fre.19h1_release.190318-1202

SYSTEM_MANUFACTURER:  LENOVO

SYSTEM_PRODUCT_NAME:  20DCA020IV

SYSTEM_SKU:  LENOVO_MT_20DC_BU_Think_FM_ThinkPad E450

SYSTEM_VERSION:  ThinkPad E450

BIOS_VENDOR:  LENOVO

BIOS_VERSION:  J5ET63WW (1.34 )

BIOS_DATE:  09/26/2018

BASEBOARD_MANUFACTURER:  LENOVO

BASEBOARD_PRODUCT:  20DCA020IV

BASEBOARD_VERSION:  Not Defined

DUMP_TYPE:  1

BUGCHECK_P1: 5

BUGCHECK_P2: 0

BUGCHECK_P3: 1023

BUGCHECK_P4: ffffd808fc533e00

BUGCHECK_STR:  0x10D_5

CPU_COUNT: 4

CPU_MHZ: 893

CPU_VENDOR:  GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3d

CPU_STEPPING: 4

CPU_MICROCODE: 6,3d,4,0 (F,M,S,R)  SIG: 2B'00000000 (cache) 2B'00000000 (init)


ADDITIONAL_DEBUG_TEXT:  
You can run '.symfix; .reload' to try to fix the symbol path and load symbols.

FAULTING_MODULE: fffff8007c800000 nt

DEBUG_FLR_IMAGE_TIMESTAMP:  5cf4fafd

BUGCHECK_STR:  0x10D_5

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

CURRENT_IRQL:  0

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

LAST_CONTROL_TRANSFER:  from fffff8007f58b828 to fffff8007c9bc810

STACK_TEXT:  
ffff9b0c`b3d0ee98 fffff800`7f58b828 : 00000000`0000010d 00000000`00000005 00000000`00000000 00000000`00001023 : nt!KeBugCheckEx
ffff9b0c`b3d0eea0 fffff800`7f559e27 : 0000001e`571ef000 00000000`00000000 00000000`00000001 00000000`00000001 : Wdf01000+0x5b828
ffff9b0c`b3d0eee0 fffff800`885f2bfc : 00000000`00000000 ffff9e0e`04604380 ffff9e0d`fec5f8b0 ffff9b0c`b3d0f280 : Wdf01000+0x29e27
ffff9b0c`b3d0ef20 fffff800`885f34c6 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Cyber20UNCProvider!CA_EstablishConnection+0x40 [c:\_dev\workspace\agent-supdriver\supdriver_x64\sentineluncprovider\commagent.c @ 99]
ffff9b0c`b3d0f170 fffff800`7f31cd8a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Cyber20UNCProvider!CS_SUPMessage+0x66 [c:\_dev\workspace\agent-supdriver\supdriver_x64\sentineluncprovider\commservice.c @ 502]
ffff9b0c`b3d0f630 fffff800`7f34bf18 : ffff9b0c`b3d0f740 00000000`00000001 ffff9e0e`02efaaa0 00000000`00000000 : FLTMGR!FltGetIoPriorityHintFromCallbackData+0x15a
ffff9b0c`b3d0f690 fffff800`7f34bfd6 : ffff9e0e`02efab70 0000001e`575ff210 00000000`00000000 00000000`00000000 : FLTMGR!FltRemoveOpenReparseEntry+0x418
ffff9b0c`b3d0f6f0 fffff800`7f313f4f : ffff9e0d`faf716b0 00000000`00000002 00000000`00000000 fffff800`7ce1da15 : FLTMGR!FltRemoveOpenReparseEntry+0x4d6
ffff9b0c`b3d0f760 fffff800`7c827da9 : ffff9e0e`02efaaa0 00000000`00000000 00000000`0008801b 00000000`00000001 : FLTMGR!FltDecodeParameters+0x11ef
ffff9b0c`b3d0f7c0 fffff800`7ce15dd5 : ffff9e0e`02efaaa0 00000000`00000000 00000000`00000000 ffff9e0e`04cccbf0 : nt!IofCallDriver+0x59
ffff9b0c`b3d0f800 fffff800`7ce1572a : 00000000`00000000 00000000`0008801b 00000000`00000000 ffff9b0c`b3d0fb40 : nt!NtDeviceIoControlFile+0xce5
ffff9b0c`b3d0f8a0 fffff800`7ce15146 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtDeviceIoControlFile+0x63a
ffff9b0c`b3d0f9e0 fffff800`7c9cde98 : 00000000`00000000 ffff9b0c`b3d0fb40 ffff9e0e`0404a330 fffff800`7ce2288d : nt!NtDeviceIoControlFile+0x56
ffff9b0c`b3d0fa50 00007ffe`e453c144 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!setjmpex+0x7af8
0000001e`575febe8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffe`e453c144


STACK_COMMAND:  kb

FOLLOWUP_IP: 
Cyber20UNCProvider!CA_EstablishConnection+40 [c:\_dev\workspace\agent-supdriver\supdriver_x64\sentineluncprovider\commagent.c @ 99]
fffff800`885f2bfc 48833d4c45000000 cmp     qword ptr [Cyber20UNCProvider!CA_agentFileObject (fffff800`885f7150)],0

FAULTING_SOURCE_LINE:  c:\_dev\workspace\agent-supdriver\supdriver_x64\sentineluncprovider\commagent.c

FAULTING_SOURCE_FILE:  c:\_dev\workspace\agent-supdriver\supdriver_x64\sentineluncprovider\commagent.c

FAULTING_SOURCE_LINE_NUMBER:  99

FAULTING_SOURCE_CODE:  
    95:   NTSTATUS                    status;
    96: 
    97:   WdfWaitLockAcquire(CA_agentFileObjectLock, NULL);
    98: 
>   99: if (CA_agentFileObject != NULL)
   100: {
   101:              LoggerLog(LOGGER_LS_WARN, L"CommAgent.c", L"CA_EstablishConnection", L"Communication with the Agent is already established");
   102: 
   103:              WdfWaitLockRelease(CA_agentFileObjectLock);
   104: 


SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  Cyber20UNCProvider!CA_EstablishConnection+40

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Cyber20UNCProvider

IMAGE_NAME:  Cyber20UNCProvider.sys

BUCKET_ID:  WRONG_SYMBOLS

FAILURE_BUCKET_ID:  WRONG_SYMBOLS

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:wrong_symbols

FAILURE_ID_HASH:  {70b057e8-2462-896f-28e7-ac72d4d365f8}

Followup: MachineOwner

作为崩溃命令，windbg标记行99，我检查了它，发现高于99的行导致了问题："WdfWaitLockAcquire(CA_agentFileObjectLock，NULL);“

守则：

这个函数在第三行出现了问题。

NTSTATUS CA_EstablishConnection()
{
    UNICODE_STRING  agentIrpBusName;
    NTSTATUS        status;

    WdfWaitLockAcquire(CA_agentFileObjectLock, NULL);

    if (CA_agentFileObject != NULL)
    {
        LoggerLog(LOGGER_LS_WARN, L"CommAgent.c", L"CA_EstablishConnection", L"Communication with the Agent is already established");

        WdfWaitLockRelease(CA_agentFileObjectLock);

        return STATUS_SUCCESS;
    }

    RtlUnicodeStringInit(
        &agentIrpBusName,
        AS_IRPBUS_SUP_AGENT_NAME
        );

    // Connect to the Agent.
    status = IoGetDeviceObjectPointer(
        &agentIrpBusName,
        FILE_ALL_ACCESS,
        &CA_agentFileObject,
        &CA_agentDeviceObject
        );

    if (status != STATUS_SUCCESS)
    {
        wchar_t strBuff[256];
        swprintf_s(strBuff, 256, L"Cannot connect to the Agent. Reason: 0x%x", status);
        LoggerLog(LOGGER_LS_ERROR, L"CommAgent.c", L"CA_EstablishConnection", strBuff);
    }

    WdfWaitLockRelease(CA_agentFileObjectLock);

    return status;
}

更多关于这个问题的笔记

• KMDF 1.29尚未释放
• Microsoft提到WDF中没有任何功能更改。
• 正如我之前提到的，在最后一次Windows 10更新之前，代码没有任何错误(该软件正在生产中)

Answer 1

您只通过了部分转储输出。您需要在windbg中打开转储并运行！分析-v命令。我肯定你会得到这样的东西：

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.

Arguments:
Arg1: 0000000000000005, A framework object handle of the incorrect type was passed to
a framework object method.
Arg2: 0000000000000000, The handle value passed in.
Arg3: 0000000000001023, Reserved.

我为什么这么想？因为查看下一行

00000000`0000010d 00000000`00000005 00000000`00000000 00000000`00001023 : nt!KeBugCheckEx

这意味着KeBugCheckEx(10d, 5, 0, 1023, *)被调用，其中10d是WDF_VIOLATION，5是WDF_INVALID_HANDLE，1023是FX_TYPE_WAIT_LOCK。所以

KeBugCheckEx(WDF_VIOLATION, WDF_INVALID_HANDLE, 0, FX_TYPE_WAIT_LOCK, *)

被称为。这意味着使用0值传递无效的锁对象句柄(因为WDF_INVALID_HANDLE__，FX_TYPE_WAIT_LOCK)来调用WdfWaitLockAcquire。

您还必须安装pdb文件(对于Wdf01000.sys和ntoskrnl.exe) --在本例中，您将查看FxVerifierBugCheckWorker调用而不是Wdf01000+0x5b828

所以在调用WdfWaitLockAcquire(CA_agentFileObjectLock, NULL);时

CA_agentFileObjectLock == NULL，为什么你发布的信息中看不到这个？