Windows 10 Enterprise 1709 driver issues when the machine joined the domain RRS feed

All replies

  • I can confirm this as well. I'm testing a Dell 5580 at the moment and have exactly same issues. We're running Credential Guard/Device Guard and the Mousepad/Audio and Intel ME drivers stop working as soon as I join the device to the domain where CG/DG is enforced. Same blue screen when rebooting the machine as well.

    When I leave the domain, turn Device Guard off and reboot the machine everything suddenly starts working again.

    Windows 10 1703 works fine. Very, very strange.

    Friday, October 20, 2017 1:03 PM
  • I had the same issues w/ two machines from Dell and Schenker (Clevo barebone).

    After extensive testing it seems that the group policy

    "Computer -> Admin.Templ. -> Windows Components -> Bitlocker Drive Encryption -> Disable new DMA devices when this computer is locked"

    is the root cause of the issues. As soon as this setting is enabled the trouble starts. When setting it to "Not configured" everything works as expected.

    • Proposed as answer by JSp42 Saturday, October 21, 2017 2:15 PM
    Saturday, October 21, 2017 2:11 PM
  • Question is: Why is this setting causing issues with 1709? We have this setting enabled as well because we followed the Windows Security Baseline for our GPO settings and it was recommended to turn it on.

    - Works fine in 1703
    - Apparently doesn't work in 1709

    Monday, October 23, 2017 5:09 AM
  • Same here. Same solution :-)

    Hm, why would microsoft's developers NOT use that DMA policy themselves? It is important :-|

    Monday, October 23, 2017 7:17 AM
  • same same (with HP EliteBook 840 G3)
    Wednesday, October 25, 2017 1:14 PM
  • "Great" :-|

    Daniel, others, please upvote this thread, I guess it will help Microsoft to identify real pain-causing issues.

    Wednesday, October 25, 2017 1:18 PM
  • I will feedback this issue in our platform. 

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Thursday, October 26, 2017 12:47 AM
  • Thank you very much, Kate!
    Thursday, October 26, 2017 8:11 AM
  • We have the same problem with Lenovo X260 and Surface Pro 3. It occurs when we configure "Disable new DMA devices when this computer is locked => enabled"
    Thursday, October 26, 2017 8:23 AM
  • Any news on this issue? Disabling the GPO isn't an option and we are unable to move forward to the FCU at the moment.
    Tuesday, October 31, 2017 6:27 AM
  • This issue has been feedback, and it will be fixed in next release. 

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, October 31, 2017 8:51 AM
  • Thanks for your response! I hope you mean the next patch build and not Redstone 4?
    Tuesday, October 31, 2017 12:01 PM
  • Maybe next monthly Windows updates. 

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Wednesday, November 1, 2017 8:13 AM

    Go to "Device Manager"< Universal Serial Bus Controllers< right click on all and click Power Management Tab< Uncheck Allow the computer to turn off this device to save power< Reboot

    Monday, November 6, 2017 4:18 PM
  • Justin, what did the "fix" help you with, a USB device? For me, it's an audio device that is affected, I wonder why that would care for USB settings. But I will try it nevertheless...tomorrow.
    Monday, November 6, 2017 6:56 PM
  • Justin, this had no effect here. Can you please share what device you could cure with that measure?
    Tuesday, November 7, 2017 7:46 AM
  • All: could you test whether today's updates solved it? Installed them and the problem vanished here.
    Tuesday, November 14, 2017 10:04 PM
  • Nope - no change on my Dell XPS 15. (16299.64 x64 Enterprise Eng)

    DMA policy enabled: Reboot takes ages w/ the spinner showing. A bunch of devices are not working (including the touchpad :-( ).

    Policy disabled: Everything is fine again

    Tuesday, November 14, 2017 10:24 PM
  • Eagerly patched my Windows 10 1709 image to build 16299.64 but the issue isn't fixed unfortunately.

    Disabling the DMA policy fixes this but we really want to ENABLE this policy.

    This means that we still can't upgrade our fleet to FCU and are forced to continue deploying CU.

    Can anyone from Microsoft respond with an estimated ETA for a fix?

    Wednesday, November 15, 2017 1:10 PM
  • Sorry, my mistake - the bug is still there. The reason I thought it was patched away is that I RDP'd into my computer and with RDP, you have a virtual audio device which works - while the real audio device when logging on normally, still won't start with the DMA policy enabled. Sorry.
    Wednesday, November 15, 2017 4:12 PM
  • KateLi, you said, it will be fixed - do you have new info when this will be fixed? Please let us know, if you have, because this will allow to schedule the rollout of 1709.
    Tuesday, November 28, 2017 9:26 AM
  • 16299.98 - still not fixed.
    Thursday, November 30, 2017 10:23 PM
  • I guess that this issue is on the bottom of the “to fix list”. It would help if anyone from Microsoft would respond to this thread with an indication when it’s fixed...
    Friday, December 1, 2017 1:25 PM
  • 16299.125 - still not fixed.
    Tuesday, December 12, 2017 7:51 PM
  • Never gonna happen mate, have you not seen the new Microsoft Tech Support model?

    1.)  Refuse to acknowledge problem exists even when evidence clearly shows it does.

    2.)  Ignore all and any support requests - DO NOT under any circumstance respond to Microsoft tech support channels requesting help.

    3.)  Wait till the users get fed up with the silence and decide to find their own fix.

    4.)  Wait till said user updates the forum with his fix and then start posting this fix in forums attributing the credit for the fix to Microsoft.

    oh and 5.)  Delete any posts in forums pointing our our new crappy tech support model!

    Friday, December 15, 2017 10:12 AM
  • Look, do you consider this forum to be the right means of starting a call for support? A quick look at what "moderation" and "CSGs" do here regularly shows that you shouldn't believe in it: they tell you what you already know (unless you are not a complete non-techie) and how things should work.

    Open a support call, give them reproducible steps on hardware they can easily aquire (or send a hardware sample), and they'll look into it.

    I guess this is a minor issue, very few machines affected. I have installed some more instances of 1709 (all have the DMA policy active) and no problem seen on those hardware types, nor on VMs. Just one machine type here so far: Asrock H97 Pro4 board, Bios P2.00, clean installation of win10 ent. x64 - "Intel display audio" chip does not work (code 10), HW-ID 


    neither works the other chip from realtek ("High definition audio")



    We will start the test rollout using one machine per device type in 3 weeks and see what happens.

    Friday, December 15, 2017 10:35 AM
  • Microsoft has now released a KB for this:

    Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.

    This forum post is my own opinion and does not necessarily reflect the opinion or view of my employer, Microsoft, its employees, or MVPs.

    Twitter: @alexverboon | Blog: Anything About IT

    • Proposed as answer by JSp42 Friday, December 15, 2017 12:39 PM
    Friday, December 15, 2017 10:44 AM
  • LOL!


    Contact the computer OEM that make the OS if the firmware is incorrect.

    Contact the external device driver manufactory if the drivers for the malfunctioning external devices are incorrect.


    Microsoft, please start redacting your articles before publishing, look at the language :-)

    But ok, I will take this link and contact the "driver manufactory" at both intel, realtek and eventually Asrock...

    Thanks for sharing, Alex!

    Friday, December 15, 2017 10:50 AM
  • Not a very helpful KB, especially when I have an affected Surface Pro 4 and MS are the OEM lol.

    I've created a GPO for this issue and pushed it to an affected client.  It worked fine until I rebooted the device and now the issue has returned.

    Monday, December 18, 2017 3:41 PM
  • My Problem is, that no Network Connection can establish after activating the policy.
    How i can Disable the Policy without a Network Connection.

    Tuesday, December 19, 2017 10:01 AM
  • Surface pro 4 is affected? Cool. Firmware and drivers up2date?

    Microsoft, where is the documentation?

    Where are hardware compatibility lists that are kept current so they reflect what devices are fully compatible with all win10 settings we might want to set?

    What I find is which seems pretty useless since it is not current but for the latest OS mentioned is 1607, outdated for 17 months! Does that list even feature Microsoft's own products like surfaces? No? No! Well, they have to be compatible, then, right? LOL.

    So in this thread, the 2nd posting mentions a Dell Latitude 5580 - it is on the list and said to be compatible with 1607 - Who cares? Oh, we should care... the policy emerged with v1703, but it was already able to set the registry key and make it work in v1607... But hey, back then, Microsoft did not enforce the policy "consistently".

    You offer a new policy but don't apply it "consistently" and when you start applying it consistently, hardware fails to work, but hey, it's not your problem, anyway. Even when devices are on that list, the disclaimer tells us "Microsoft makes no representations or warranties, expressed, implied or statutory, regarding the items, manufacturers or compatibility of the items depicted or described."


    I urge MS not to introduce measures that affect hardware like that and not at the same time notify customers and offer a list of hardware that you tested with successfully, nor give them a tool that could test whether some "BME bit" is set correctly or not.

    Tuesday, December 19, 2017 1:40 PM
  • I would try to import these registry settings:

    Windows Registry Editor Version 5.00

    and than reboot.

    Tuesday, December 19, 2017 1:55 PM
  • We had same issue.  Found a blog post from MS Security. 

    They know it's issue and they are working on the solution with no date.  In the meantime, internal security does not want to disable this setting and we can't roll out 1709!

    Wednesday, January 24, 2018 9:02 PM
  • Aha... 1st they say, it's a driver problem, now they say it's their problem as well. Great, thank you, desertpole.

    Thursday, January 25, 2018 7:41 AM
  • still horribly broken as of the february rollup... We turned it on and basically broke all of our laptops.
    Wednesday, March 7, 2018 9:59 PM
  • Finally!!!

    With 1803 (Build 17133.1) my computers work again w/ "Disable new DMA devices when this computer is locked" enabled.

    All drivers are properly started.

    Saturday, April 7, 2018 6:22 PM
  • And for 1709 as well.

    With update KB4093105 bringing the OS to 16299.402 the DMA problem is fixed.

    From the update description:

    Addresses an issue that prevents certain devices from working on Windows 10, version 1709, machines when the “Disable new DMA devices when this computer is locked” Group Policy is active. The non-working devices are internal, PCI-based peripherals (wireless network drivers and input and audio peripherals). These peripherals can fail on systems whose firmware blocks the peripherals from performing Direct Memory Access (DMA) at boot.

    Tuesday, April 24, 2018 9:24 AM