Graphics stack bug - Windows 10 Build Threshold Release (10586+, including RedStone) RRS feed

  • Question

  • Hello, 

    Cross-posted from Microsoft Answers as advised there:

    A little old, but still seems relevant and the issue seems to persist with recent builds.

    Quick context story of the problem: A few weeks ago, being on the insider Fast ring I updated myself to the first release based on the Redstone build. My laptop was a HP Envy 15 with an Nvidia Optimus based GeForce 950M, and Intel HD Graphics 5500. However, I noticed weird issues as my screen turned black (but didn't switch off), and the cursor was occasionally visible once every 5-10 seconds or so (but cursor response took about 20-30 seconds). Strange. Most reasonable guess was the graphics driver. Hard reset of the laptop, and everything seemed to be quite fine. Strangely, there were no memory dumps (since the system actually didn't crash I guess), but fortunately the event logs did have a never ending list of "Graphics card crashed and recovered unexpectedly." 

    The RedStone update also ended up in weird bugs and event logs filled with errors, mostly due to COM permission issues and so on. Meanwhile, a few hours later, there was an update available for my Intel HD 5500. Great, I was optimistic the issue was getting fixed. However, installing the driver (through Windows Update), ended up in the same blank screen again. Another hard reset, where Windows recovered itself to the last known state, and with similar errors. Meanwhile, my Nvidia card had an update. That was fast. Perhaps, that was the missing piece, and the Nvidia driver this time - same results. Blank screen. Another hard reset, but now I decided to do a full reset. (This was two days before it was documented that the RedStone build Reset ended up in an unusable system completely breaking it requiring a fresh clean install). 

    So, there it was. Now, I decided that I had enough with the new RedStone build, and move back to 10586 - the stable build. To my surprise, the graphics drivers ended up with the same result, and blank screen! Another hard reset and the graphics driver worked however. It always seemed to crash repeatedly during the install. However, thankfully, this time, I ended up with a lot of LiveKernelReports! Now we are getting somewhere. But a bit too many memorydumps.

    Image of numerous dumps

    493 minidumps. Alright, naturally, next step was to figure out what was wrong. So, WinDbg for all of them resulted in the following call stack:

    0: kd> k
     # Child-SP          RetAddr           Call Site
    00 ffffd000`275c3a00 fffff800`9d7671fc watchdog!WdDbgReportRecreate+0x104
    01 ffffd000`275c3a50 fffff800`9d76675f dxgkrnl!TdrUpdateDbgReport+0xec
    02 ffffd000`275c3aa0 fffff800`9d753345 dxgkrnl!TdrCollectDbgInfoStage2+0x1df
    03 ffffd000`275c3ad0 fffff800`9d766e65 dxgkrnl!DXGADAPTER::Reset+0x21d
    04 ffffd000`275c3b20 fffff800`9d766fbb dxgkrnl!TdrResetFromTimeout+0x15
    05 ffffd000`275c3b50 fffff803`35e78b79 dxgkrnl!TdrResetFromTimeoutWorkItem+0x5b
    06 ffffd000`275c3b80 fffff803`35e17125 nt!ExpWorkerThread+0xe9
    07 ffffd000`275c3c10 fffff803`35f55916 nt!PspSystemThreadStartup+0x41
    08 ffffd000`275c3c60 00000000`00000000 nt!KiStartSystemThread+0x16

    Ok, that was "dxgkrnl" - the graphics stack. Next up the analysis ended up with straight forward message:

    The display driver failed to respond in timely fashion.
    (This code can never be used for a real bugcheck.)
    Arg1: ffffe0011e57d4c0, Optional pointer to internal TDR recovery context (TDR_RECOVERY_CONTEXT).
    Arg2: fffff800a4c620f0, The pointer into responsible device driver module (e.g owner tag).
    Arg3: 0000000000000000, The secondary driver specific bucketing key.
    Arg4: 0000000000000000, Optional internal context dependent data.
    Debugging Details:
    BUILD_VERSION_STRING:  10586.63.amd64fre.th2_release.160104-1513
    DUMP_TYPE:  2
    BUGCHECK_P1: ffffe0011e57d4c0
    BUGCHECK_P2: fffff800a4c620f0
    BUGCHECK_P3: 0
    BUGCHECK_P4: 0
    fffff800`a4c620f0 ??              ???
    TAG_NOT_DEFINED_202b:  *** Unknown TAG in analysis list 202b
    CPU_COUNT: 4
    CPU_MHZ: 95a
    CPU_VENDOR:  GenuineIntel
    CPU_MODEL: 3d
    BUGCHECK_STR:  0x117
    PROCESS_NAME:  System
    ANALYSIS_SESSION_TIME:  02-15-2016 06:26:31.0556
    ANALYSIS_VERSION: 10.0.10586.567 amd64fre
    ffffd000`275c3a00 fffff800`9d7671fc : ffffe001`1e57d4c0 00000000`80000000 ffffe001`1e57d4c0 ffffe001`32fd3010 : watchdog!WdDbgReportRecreate+0x104
    ffffd000`275c3a50 fffff800`9d76675f : ffffc000`00000000 ffffc000`cb9f1500 ffffe001`1e57d4c0 ffffe001`33482408 : dxgkrnl!TdrUpdateDbgReport+0xec
    ffffd000`275c3aa0 fffff800`9d753345 : ffffc000`d1c89c24 ffffe001`334823a0 ffffe001`334823a0 ffffe001`33482408 : dxgkrnl!TdrCollectDbgInfoStage2+0x1df
    ffffd000`275c3ad0 fffff800`9d766e65 : ffffe001`32370150 00000000`00000000 00000000`00000000 00000000`00000000 : dxgkrnl!DXGADAPTER::Reset+0x21d
    ffffd000`275c3b20 fffff800`9d766fbb : 00000000`00000200 fffff803`361a1340 ffffe001`1c208c90 fffff803`35e90910 : dxgkrnl!TdrResetFromTimeout+0x15
    ffffd000`275c3b50 fffff803`35e78b79 : ffffe001`333c7040 fffff800`9d766f60 ffffe001`1fe25610 fffff803`361a1340 : dxgkrnl!TdrResetFromTimeoutWorkItem+0x5b
    ffffd000`275c3b80 fffff803`35e17125 : 00000005`b19bbdff 00000000`00000080 ffffe001`1b8a2040 ffffe001`333c7040 : nt!ExpWorkerThread+0xe9
    ffffd000`275c3c10 fffff803`35f55916 : ffffd000`20720180 ffffe001`333c7040 fffff803`35e170e4 ffeceff1`ffeceff1 : nt!PspSystemThreadStartup+0x41
    ffffd000`275c3c60 00000000`00000000 : ffffd000`275c4000 ffffd000`275be000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16
    THREAD_SHA1_HASH_MOD_FUNC:  26032a29a837a16b5eba8813d816bfe6c3aea8a7
    THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  2a98f27881b30ef00b3362f6f34c45e22e7dcaf5
    THREAD_SHA1_HASH_MOD:  7558c67383100ca76738f2615528c656f1c43af3
    fffff800`a4c620f0 ??              ???
    SYMBOL_NAME:  igdkmd64+120f0
    FOLLOWUP_NAME:  MachineOwner
    MODULE_NAME: igdkmd64
    IMAGE_NAME:  igdkmd64.sys
    FAILURE_BUCKET_ID:  LKD_0x117_IMAGE_igdkmd64.sys
    BUCKET_ID:  LKD_0x117_IMAGE_igdkmd64.sys
    PRIMARY_PROBLEM_CLASS:  LKD_0x117_IMAGE_igdkmd64.sys
    TARGET_TIME:  2016-02-02T11:24:05.000Z
    OSBUILD:  10586
    SUITE_MASK:  272
    OSNAME:  Windows 10
    OSEDITION:  Windows 10 WinNt TerminalServer SingleUserTS
    USER_LCID:  0
    OSBUILD_TIMESTAMP:  2016-01-05 06:58:56
    BUILDDATESTAMP_STR:  160104-1513
    BUILDLAB_STR:  th2_release
    BUILDOSVER_STR:  10.0.10586.63.amd64fre.th2_release.160104-1513
    FAILURE_ID_HASH_STRING:  km:lkd_0x117_image_igdkmd64.sys
    FAILURE_ID_HASH:  {df5cc292-6e03-34f8-7849-e22c43f13df4}

    I'd have generally chalked it up as an Intel driver issue and moved on, however, interesting I received about 2 or 3 different updates from Windows Update for the same Intel Graphics driver. Windows update seemed to have been the most reliable place for drivers which are expected to have been well tested, but all of them ended up crashing exactly the same way. 

    I do have one full memory dump that I'd be happy to share but since its a system wide dump, not something I can share publicly, and very large as well. This issue didn't exist before the 10586 build, but seems to exist in all later insider builds till date.

    I could share the watchdog dumps, but since there are kernel dumps, I'm reluctant to share it publicly. I remember being able to share confidentially with Microsoft on Connect, however that seems unavailable here. Please let me know how to proceed. 

    UPDATE: Brief analysis and more details here for reference:

    Thursday, May 19, 2016 12:36 PM

All replies

  • Prasanna,

    I replied regarding how to share dumps in forums here in your another thread.

    For the Video driver issue here, please first boot into BIOS and verify the Hardware health there; there should be hardware tools available in BIOS.

    Further, boot into safe mode, download the proper Video driver from the manufacturer website, then uninstall the old driver and manually install the download one, once finished, restart to check.

    If issue still insists, submit through Windows Feedback Tool.


    Please mark the reply as an answer if you find it is helpful.

    If you have feedback for TechNet Support, contact

    Friday, May 20, 2016 5:52 AM
  • Thanks for the reply. Yes, I've checked all the UEFI Diagnostics when the issue happened repeatedly. All of them seem to be fine. Besides, older builds of Windows, coupled with older drivers (as well as my Linux OSes - though that might not necessarily prove anything in this context) doesn't seem to have this issue. This is on the retail build (10586). And the same thing happens on Safe Mode as well during the installation. It generates numerous minidumps. My unscientific guess - Seems like the driver fails on infinitely, but just not quickly enough for the watch dog to catch it and crash. So, it ends up on a blank screen instead of BSOD.

    The Insider builds for some reason didn't generate the minidumps which were generated on the retail build. (Note that I haven't tried this on the recent insider build of the past 2 months though, after this issue plagued it during the first 3-4 RedStone builds on my system). 

    Also, Windows Feedback Tool on the retail build has the option to submit memory dumps? (If so I can't seem to find that). Will upload some of the minidumps, and share it here soon.

    The most consistent way to end up with the issue on the retail build seems to be to upgrade beyond anything RedStone, and then fallback to the today's most recent retail build on 10586. This always magnifies the issue. (However it also happens on fresh install of retail, but seem to be inconsistent). 

    Friday, May 20, 2016 7:06 AM
  • Hello Michael,

    I've shared the Kernel Watchdog Dumps. There are 493 minidumps that were created. These were the only dumps that were generated, and my guess is that, it probably would only end up in where the timeout happens, and likely provide an insight into the problem driver, though not helping much with the precise problem in the driver. But there was nothing more that was generated. Please let me know if there's anything more that I can share to help. 

    LiveKernelReports - Watchdog Dumps!50159&authkey=!ACXvi3JBeIKyl58&ithint=file%2c7z

    Please let me know when they've been downloaded so I can delete them. Thanks.

    Tuesday, May 24, 2016 6:28 AM
  • WER Kernel Reports that fail on igdkmd64 module: 



    Update: I've organized all the dumps into one shared folder: 


    Tuesday, May 24, 2016 6:36 AM
  • Hi,

    This is downloaded.

    For verify the account, see:


    Please mark the reply as an answer if you find it is helpful.

    If you have feedback for TechNet Support, contact

    Wednesday, May 25, 2016 3:28 AM