none
Windows Server 2019 自动生成ResourceTimeout.dmp文件 RRS feed

  • 问题

  • 您好

        有两台Win2019虚拟机(使用VMware Vsphere6.7)组建MSCS集群,集群安装sql server 2019,运行过程中不定期就会在c:\windows\LiveKernelReports下生成ResourceTimeout.dmp文件。

    使用windbg工具分析结果如下,请大神帮忙看下什么原因引起的,谢谢!

    Loading Dump File [C:\Users\Administrator\Desktop\ResourceTimeout.dmp]
    Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.

    Symbol search path is: srv*
    Executable search path is: 
    Windows 10 Kernel Version 17763 MP (8 procs) Free x64
    Product: Server, suite: TerminalServer DataCenter SingleUserTS
    Built by: 17763.1.amd64fre.rs5_release.180914-1434
    Machine Name:
    Kernel base = 0xfffff806`1eea3000 PsLoadedModuleList = 0xfffff806`1f2bd730
    Debug session time: Fri Jan 22 17:44:27.265 2021 (UTC + 8:00)
    System Uptime: 26 days 21:18:30.320
    Loading Kernel Symbols
    ...............................................................
    ................................................................
    ....................................................
    Loading User Symbols

    Loading unloaded module list
    ............
    For analysis of this file, run !analyze -v
    0: kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    EXRESOURCE_TIMEOUT_LIVEDUMP (1cc)
    A kernel ERESOURCE has timed out. This can indicate a deadlock condition or
    heavy contention which can cause performance issues.
    Arguments:
    Arg1: ffff98049cefdb70, The ERESOURCE that has timed out
    Arg2: ffff9804a039c080, The thread that detected the timeout
    Arg3: 00000000000001e7, The ERESOURCE contention count
    Arg4: 0000000000000096, The configured timeout in seconds

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


    KEY_VALUES_STRING: 1

        Key  : Analysis.CPU.Sec
        Value: 3

        Key  : Analysis.DebugAnalysisProvider.CPP
        Value: Create: 8007007e on WIN-42KD1B3O3H7

        Key  : Analysis.DebugData
        Value: CreateObject

        Key  : Analysis.DebugModel
        Value: CreateObject

        Key  : Analysis.Elapsed.Sec
        Value: 3

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

        Key  : Analysis.System
        Value: CreateObject


    VIRTUAL_MACHINE:  VMware

    DUMP_FILE_ATTRIBUTES: 0x10
      Live Generated Dump

    BUGCHECK_CODE:  1cc

    BUGCHECK_P1: ffff98049cefdb70

    BUGCHECK_P2: ffff9804a039c080

    BUGCHECK_P3: 1e7

    BUGCHECK_P4: 96

    FAULTING_THREAD:  ffff9804a59b1080

    PROCESS_NAME:  System

    STACK_TEXT:  
    ffffe482`387c6e10 fffff806`1ef67577 : ffff9804`a59b1080 00000000`00000000 ffffd300`a1fb5200 ffffe482`387c7000 : nt!KiSwapContext+0x76
    ffffe482`387c6f50 fffff806`1ef670e9 : ffffbae3`97e44627 ffff9804`a2d78350 00000000`00000000 ffff9804`9e42c4b0 : nt!KiSwapThread+0x297
    ffffe482`387c7010 fffff806`1ef65e70 : 0000007f`ffffff00 ffff9804`00000000 00000000`00000000 ffffe482`387c7121 : nt!KiCommitThreadWait+0x549
    ffffe482`387c70b0 fffff806`1f52fdbb : ffff9804`88875d00 ffffac00`00000000 00000000`00000000 ffffd300`a1fab401 : nt!KeWaitForSingleObject+0x520
    ffffe482`387c7180 fffff806`1f52f6e7 : ffff9804`88875c58 ffff9804`a12b9bc0 00000000`00000000 fffff806`1ef72fbc : nt!FsRtlCancellableWaitForMultipleObjects+0xcb
    ffffe482`387c71f0 fffff806`1dc01090 : ffff9804`88875d00 ffff9804`a9d032a0 ffff9800`a7015a21 ffff9804`a59b1080 : nt!FsRtlCancellableWaitForSingleObject+0x27
    ffffe482`387c7230 fffff806`1dcab661 : ffffe482`387c7350 ffff9804`a59d2ec0 ffffbf8f`12032e98 ffff9804`a12b9bc0 : mrxsmb!SmbCeWaitForCompletionAndFinalizeExchangeEx+0x80
    ffffe482`387c7300 fffff806`1dc1bbe5 : ffff9804`88875c58 00000000`00000000 ffff9804`a12b9bc0 00000000`40000010 : mrxsmb20!MRxSmb2QueryDirectory+0xe381
    ffffe482`387c7350 fffff806`22542949 : ffff9804`a12b9bc0 ffff9804`a59d2d60 00000000`00000000 ffff9804`a59d2ec0 : mrxsmb!SmbShellQueryDirectory+0x25
    ffffe482`387c7380 fffff806`22542649 : ffff9804`a12b9bc0 ffff9804`a59d2d60 ffffbf8f`15213050 ffff9804`a12b9b00 : rdbss!RxQueryDirectory+0x2c5
    ffffe482`387c7400 fffff806`22503015 : ffff9804`a12b9bc0 ffffbf8f`12032e98 ffffbf8f`15213050 ffff9804`a59d2d01 : rdbss!RxCommonDirectoryControl+0x99
    ffffe482`387c7470 fffff806`2253e506 : ffff9804`87e02340 ffff9804`00000000 ffff9804`a59d2d60 fffff806`1f0dd80c : rdbss!RxFsdCommonDispatch+0x5c5
    ffffe482`387c75f0 fffff806`1dc57afc : 00000000`00000000 ffffbf8e`fe9bc000 ffffbf8e`e9e00340 fffff806`1f0dd80c : rdbss!RxFsdDispatch+0x86
    ffffe482`387c7640 fffff806`1efad059 : ffff9804`9eef2b20 ffff9804`a59d2d60 ffffbf8e`ecfd4870 ffff9804`98be69e0 : mrxsmb!MRxSmbFsdDispatch+0xfc
    ffffe482`387c7690 fffff80e`518dd8b0 : fffff80e`518d8000 ffff9804`9b15f7c0 ffff9804`9b140dc0 ffff9804`a7b24618 : nt!IofCallDriver+0x59
    ffffe482`387c76d0 fffff80e`518dd3e9 : ffffbf8e`ecfd4870 ffff9804`9b15f7c0 fffff80e`518d8000 00000000`00000000 : mup!MupiCallUncProvider+0xb0
    ffffe482`387c7740 fffff80e`518dd32a : ffff9804`a59d2d60 ffff9804`a7b24610 ffff9804`a1c7d510 00000000`00000000 : mup!MupStateMachine+0x59
    ffffe482`387c7770 fffff806`1efad059 : 00000000`00000000 00000000`00000000 ffff9804`9eef2b20 00000000`00000000 : mup!MupFsdIrpPassThrough+0x17a
    ffffe482`387c77e0 fffff80e`50126219 : 00000000`00000000 ffffe482`387c78b0 ffff9804`a59d2d60 ffffe482`387c78c0 : nt!IofCallDriver+0x59
    ffffe482`387c7820 fffff80e`50124a36 : ffffe482`387c78b0 ffff9804`98d6ace0 00000000`02ff73c8 ffff9804`9b18a940 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x289
    ffffe482`387c7890 fffff806`1efad059 : ffff9804`a59d2d60 fffff806`1efae867 00000000`00000004 ffffe482`387c7904 : FLTMGR!FltpDispatch+0xb6
    ffffe482`387c78f0 fffff806`1f5162d1 : ffffe482`387c7b80 ffff9804`a59d2d60 00000000`00000001 ffff9804`a1c7d510 : nt!IofCallDriver+0x59
    ffffe482`387c7930 fffff806`1f43b9cf : 00000000`000009b8 00000000`00000000 00000000`00000000 ffffe482`387c7b80 : nt!IopSynchronousServiceTail+0x1b1
    ffffe482`387c79e0 fffff806`1f06bd05 : ffff9804`a59b1080 ffffe482`387c7b80 00000000`02ff6378 ffffe482`387c7aa8 : nt!NtQueryDirectoryFileEx+0xbf
    ffffe482`387c7a90 00007ffa`de711eb4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25
    00000000`02ff73a8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffa`de711eb4


    STACK_COMMAND:  .thread 0xffff9804a59b1080 ; kb

    SYMBOL_NAME:  mrxsmb!SmbCeWaitForCompletionAndFinalizeExchangeEx+80

    MODULE_NAME: mrxsmb

    IMAGE_NAME:  mrxsmb.sys

    BUCKET_ID_FUNC_OFFSET:  80

    FAILURE_BUCKET_ID:  LKD_0x1cc_EXRESOURCE_TIMEOUT_OWNERTHREAD_mrxsmb!SmbCeWaitForCompletionAndFinalizeExchangeEx

    OS_VERSION:  10.0.17763.1

    BUILDLAB_STR:  rs5_release

    OSPLATFORM_TYPE:  x64

    OSNAME:  Windows 10

    FAILURE_ID_HASH:  {40f2df19-d5bf-8e06-391b-ebef2c195ba0}

    Followup:     MachineOwner

    2021年3月5日 8:46

全部回复

  • 你好,

    LiveDump可以看为是系统的一个特性,区别于crash dump的地方就是LiveDump是实时转储,它允许您创建内核内存的一致快照,并将其保存到转储文件中,以便将来进行分析。获取该快照不会导致错误检查,因此不会导致停机。

    根据您提供的信息来看,这更像是因为high I/O导致资源访问超时。

    EXRESOURCE_TIMEOUT_LIVEDUMP (1cc)
    A kernel ERESOURCE has timed out. This can indicate a deadlock condition orheavy contention which can cause performance issues.

    官方文档没有给出一个具体的信息。

    https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x1cc--exresource-timeout-livedump

    但是dump指出可能是mrxsmb.sys存在问题,通常在客户机上,应用程序通过请求对远程文件的操作来执行系统调用。这些请求由重定向子系统(rdbss.sys)和SMB迷你重定向器(mrxsmb.sys)处理,两者都将请求转换为SMB协议会话和TCP/IP上的请求。所以建议您可以检查系统安全更新,安装更新来更新mrxsmb.sys文件版本。

    同时请您理解由于我们的安全政策,这是一个公共论坛,为了更好的保护您的个人信息,我们无法提供转储/日志分析,请您谅解。如果这个问题对你来说更紧急,后续有问题我还是建议你打开一个案例给微软进一步的专业帮助。

    https://support.microsoft.com/en-us/help/4341255/support-for-busines

    如果回答是有帮助的请将其标记为答案可以帮助其他有相同问题的社区成员并快速找到有用的答复。


    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。

    2021年3月8日 7:54
  • 收到,谢谢您的回复。
    2021年3月8日 8:41
  • 你好,

    感谢您的回复。

    如果有问题,您随时联系。我正在建议有帮助的答复为 "答案"。如果回答是有帮助的请将其标记为答案可以帮助其他有相同问题的社区成员并快速找到有用的答复。


    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。

    2021年3月10日 3:11
  • 你好,

    几天没收到你的留言了, 请问问题有什么进展吗?

    我正在建议有帮助的答复为 "答案"。如果回答是有帮助的, 请将其标记为答案, 可以帮助其他有相同问题的社区成员, 并快速找到有用的答复。


    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。

    2021年3月12日 3:37