none
802.1X environment problems with authentication after 1903 update RRS feed

  • Question

  • Since the 1903 update i have been experiencing authentication problems with some windows 10 machines in our network. Are there any more information about this issue than what was suggested here: https://support.microsoft.com/en-gb/help/3121002/windows-10-devices-can-t-connect-to-an-802-1x-environment?
    Friday, August 30, 2019 7:00 AM

All replies

  • Hi,

    Thanks for posting in the forum.

    Could you describe what questions you have encountered in detail? Please post your client and NPS server log.

    Best regards,

    Hollis


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, September 2, 2019 8:08 AM
  • John,

    I am wondering if you have come across any resolution for your issue. We are experiencing a similar issue after the latest update. We get logged in on the first try but not getting our authenticated network address. We are getting one that is not on the domain. After the initial login on the other network if we unplug the network cable and plug it back in the authenticated network seems to appear and everything is okay. We have to then double click on our network drives to get them back. 

    Just wondering if this is your experience? 

    Thanks.

    Ryan

    Wednesday, September 4, 2019 12:03 PM
  • Hi,

    Just checking in to see if your question is resolved? Please let us know if you would like further assistance.

    Best regards,

    Hollis


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, September 6, 2019 8:10 AM
  • I have exact same issues. I have used several days finding cause from network and server side. Comforting that I'm not alone with this one.

    Looking from event log (Applications and Service Logs->Microsoft->Windows->Wired-Autoconfig), seems that OS does not even try to authenticate after cold boot. No problem after disconnecting/connecting LAN-cable or warm boot (restart).

    One of our trouble machines is HP EliteBook 850 G3 with Intel I219-V adapter. Older G2 with Intel I218-LM works just fine. I tried upgrading and downgrading different driver versions but issue persists.

    I would appreciate any ideas what to try next.

    Tuesday, September 10, 2019 3:27 PM
  • Hi

    We also have the similar problem, here is the server log & client log. After boot the computer if we unplug the network cable and plug it back or restart the wired autoconfig services it is authenticating & getting the IP address.

    Same issue is happening if the computer went to the sleep mode, after logon we need to unplug the cable for 802.1x authentication.

    Note: Windows 10 1903 laptops only having this issue, 1809 laptops are working fine. It is only for wired connection, wireless authentication works.


    ====================  Client Log ==================================



    ****************************  After boot the computer (network cable not unplug) ***************************

    Log Name:      Microsoft-Windows-Wired-AutoConfig/Operational
    Source:        Microsoft-Windows-Wired-AutoConfig
    Date:          2019-09-10 4:06:06 PM
    Event ID:      15500
    Task Category: None
    Level:         Information
    Keywords:      
    User:          SYSTEM
    Computer:      T460s-14129.test.org
    Description:
    The network adapter has been unplugged.

        Network Adapter: Intel(R) Ethernet Connection I219-V
        Interface GUID: {cafa7544-68a7-4145-864c-c5ce5030d1ad}
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Wired-AutoConfig" Guid="{b92cf7fd-dc10-4c6b-a72d-1613bf25e597}" />
        <EventID>15500</EventID>
        <Version>0</Version>
        <Level>4</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2019-09-10T20:06:06.161261900Z" />
        <EventRecordID>675</EventRecordID>
        <Correlation />
        <Execution ProcessID="5160" ThreadID="13348" />
        <Channel>Microsoft-Windows-Wired-AutoConfig/Operational</Channel>
        <Computer>T460s-14129.test.org</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="InterfaceGuid">{cafa7544-68a7-4145-864c-c5ce5030d1ad}</Data>
        <Data Name="InterfaceDescription">Intel(R) Ethernet Connection I219-V</Data>
      </EventData>
    </Event>

    Log Name:      Microsoft-Windows-Wired-AutoConfig/Operational
    Source:        Microsoft-Windows-Wired-AutoConfig
    Date:          2019-09-10 4:02:53 PM
    Event ID:      15501
    Task Category: None
    Level:         Information
    Keywords:      
    User:          SYSTEM
    Computer:      T460s-14129.test.org
    Description:
    The network adapter has been connected.

        Network Adapter: Intel(R) Ethernet Connection I219-V
        Interface GUID: {cafa7544-68a7-4145-864c-c5ce5030d1ad}
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Wired-AutoConfig" Guid="{b92cf7fd-dc10-4c6b-a72d-1613bf25e597}" />
        <EventID>15501</EventID>
        <Version>0</Version>
        <Level>4</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2019-09-10T20:02:53.594335100Z" />
        <EventRecordID>674</EventRecordID>
        <Correlation />
        <Execution ProcessID="5160" ThreadID="13480" />
        <Channel>Microsoft-Windows-Wired-AutoConfig/Operational</Channel>
        <Computer>T460s-14129.test.org</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="InterfaceGuid">{cafa7544-68a7-4145-864c-c5ce5030d1ad}</Data>
        <Data Name="InterfaceDescription">Intel(R) Ethernet Connection I219-V</Data>
      </EventData>
    </Event>

    Log Name:      Microsoft-Windows-Wired-AutoConfig/Operational
    Source:        Microsoft-Windows-Wired-AutoConfig
    Date:          2019-09-10 4:02:49 PM
    Event ID:      15500
    Task Category: None
    Level:         Information
    Keywords:      
    User:          SYSTEM
    Computer:      T460s-14129.test.org
    Description:
    The network adapter has been unplugged.

        Network Adapter: Intel(R) Ethernet Connection I219-V
        Interface GUID: {cafa7544-68a7-4145-864c-c5ce5030d1ad}
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Wired-AutoConfig" Guid="{b92cf7fd-dc10-4c6b-a72d-1613bf25e597}" />
        <EventID>15500</EventID>
        <Version>0</Version>
        <Level>4</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2019-09-10T20:02:49.820576700Z" />
        <EventRecordID>673</EventRecordID>
        <Correlation />
        <Execution ProcessID="5160" ThreadID="13480" />
        <Channel>Microsoft-Windows-Wired-AutoConfig/Operational</Channel>
        <Computer>T460s-14129.test.org</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="InterfaceGuid">{cafa7544-68a7-4145-864c-c5ce5030d1ad}</Data>
        <Data Name="InterfaceDescription">Intel(R) Ethernet Connection I219-V</Data>
      </EventData>
    </Event>





    *********************** After unplu the cable & plug back on client laptop

    Log Name:      Microsoft-Windows-Wired-AutoConfig/Operational
    Source:        Microsoft-Windows-Wired-AutoConfig
    Date:          2019-09-10 4:06:24 PM
    Event ID:      15505
    Task Category: None
    Level:         Information
    Keywords:      
    User:          SYSTEM
    Computer:      T460s-14129.test.org
    Description:
    Wired 802.1X Authentication succeeded.

        Network Adapter: Intel(R) Ethernet Connection I219-V
        Interface GUID: {cafa7544-68a7-4145-864c-c5ce5030d1ad}
        Peer Address: C09134FF6900
        Local Address: 507B9DFDCE89
        Connection ID: 0x6
        Identity: host/T460s-14129.test.org
        User: -
        Domain: -
        Reason: 0x0
        Reason Text: The operation was successful
        Error Code: 0x0
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Wired-AutoConfig" Guid="{b92cf7fd-dc10-4c6b-a72d-1613bf25e597}" />
        <EventID>15505</EventID>
        <Version>0</Version>
        <Level>4</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2019-09-10T20:06:24.285934400Z" />
        <EventRecordID>680</EventRecordID>
        <Correlation />
        <Execution ProcessID="5160" ThreadID="1220" />
        <Channel>Microsoft-Windows-Wired-AutoConfig/Operational</Channel>
        <Computer>T460s-14129.test.org</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="InterfaceGuid">{cafa7544-68a7-4145-864c-c5ce5030d1ad}</Data>
        <Data Name="InterfaceDescription">Intel(R) Ethernet Connection I219-V</Data>
        <Data Name="SwitchMAC">C09134FF6900</Data>
        <Data Name="LocalMAC">507B9DFDCE89</Data>
        <Data Name="ConnectionID">0x6</Data>
        <Data Name="Identity">host/T460s-14129.test.org</Data>
        <Data Name="User">-</Data>
        <Data Name="Domain">-</Data>
        <Data Name="ReasonCode">0x0</Data>
        <Data Name="ReasonText">The operation was successful</Data>
        <Data Name="ErrorCode">0x0</Data>
        <Data Name="ExplicitCredentials">false</Data>
      </EventData>
    </Event>

    Log Name:      Microsoft-Windows-Wired-AutoConfig/Operational
    Source:        Microsoft-Windows-Wired-AutoConfig
    Date:          2019-09-10 4:06:24 PM
    Event ID:      15508
    Task Category: None
    Level:         Information
    Keywords:      
    User:          SYSTEM
    Computer:      T460s-14129.test.org
    Description:
    There has been an NDIS Port state change on this network adapter.

        Network Adapter: Intel(R) Ethernet Connection I219-V
        Interface GUID: {cafa7544-68a7-4145-864c-c5ce5030d1ad}
        NDIS Control State: UnControlled
        NDIS Auth State: Authorized
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Wired-AutoConfig" Guid="{b92cf7fd-dc10-4c6b-a72d-1613bf25e597}" />
        <EventID>15508</EventID>
        <Version>0</Version>
        <Level>4</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2019-09-10T20:06:24.285823200Z" />
        <EventRecordID>679</EventRecordID>
        <Correlation />
        <Execution ProcessID="5160" ThreadID="1220" />
        <Channel>Microsoft-Windows-Wired-AutoConfig/Operational</Channel>
        <Computer>T460s-14129.test.org</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="InterfaceGuid">{cafa7544-68a7-4145-864c-c5ce5030d1ad}</Data>
        <Data Name="InterfaceDescription">Intel(R) Ethernet Connection I219-V</Data>
        <Data Name="NdisPortControlState">1</Data>
        <Data Name="NdisPortAuthState">0</Data>
      </EventData>
    </Event>

    Log Name:      Microsoft-Windows-Wired-AutoConfig/Operational
    Source:        Microsoft-Windows-Wired-AutoConfig
    Date:          2019-09-10 4:06:10 PM
    Event ID:      15503
    Task Category: None
    Level:         Information
    Keywords:      
    User:          SYSTEM
    Computer:      T460s-14129.test.org
    Description:
    Wired 802.1X Authentication was started.

        Network Adapter: Intel(R) Ethernet Connection I219-V
        Interface GUID: {cafa7544-68a7-4145-864c-c5ce5030d1ad}
        Connection ID: 0x6
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Wired-AutoConfig" Guid="{b92cf7fd-dc10-4c6b-a72d-1613bf25e597}" />
        <EventID>15503</EventID>
        <Version>0</Version>
        <Level>4</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2019-09-10T20:06:10.150439000Z" />
        <EventRecordID>678</EventRecordID>
        <Correlation />
        <Execution ProcessID="5160" ThreadID="12540" />
        <Channel>Microsoft-Windows-Wired-AutoConfig/Operational</Channel>
        <Computer>T460s-14129.test.org</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="InterfaceGuid">{cafa7544-68a7-4145-864c-c5ce5030d1ad}</Data>
        <Data Name="InterfaceDescription">Intel(R) Ethernet Connection I219-V</Data>
        <Data Name="ConnectionID">0x6</Data>
      </EventData>
    </Event>

    Log Name:      Microsoft-Windows-Wired-AutoConfig/Operational
    Source:        Microsoft-Windows-Wired-AutoConfig
    Date:          2019-09-10 4:06:10 PM
    Event ID:      15501
    Task Category: None
    Level:         Information
    Keywords:      
    User:          SYSTEM
    Computer:      T460s-14129.test.org
    Description:
    The network adapter has been connected.

        Network Adapter: Intel(R) Ethernet Connection I219-V
        Interface GUID: {cafa7544-68a7-4145-864c-c5ce5030d1ad}
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Wired-AutoConfig" Guid="{b92cf7fd-dc10-4c6b-a72d-1613bf25e597}" />
        <EventID>15501</EventID>
        <Version>0</Version>
        <Level>4</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2019-09-10T20:06:10.075411000Z" />
        <EventRecordID>677</EventRecordID>
        <Correlation />
        <Execution ProcessID="5160" ThreadID="12540" />
        <Channel>Microsoft-Windows-Wired-AutoConfig/Operational</Channel>
        <Computer>T460s-14129.test.org</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="InterfaceGuid">{cafa7544-68a7-4145-864c-c5ce5030d1ad}</Data>
        <Data Name="InterfaceDescription">Intel(R) Ethernet Connection I219-V</Data>
      </EventData>
    </Event>

    Log Name:      Microsoft-Windows-Wired-AutoConfig/Operational
    Source:        Microsoft-Windows-Wired-AutoConfig
    Date:          2019-09-10 4:06:06 PM
    Event ID:      15508
    Task Category: None
    Level:         Information
    Keywords:      
    User:          SYSTEM
    Computer:      T460s-14129.test.org
    Description:
    There has been an NDIS Port state change on this network adapter.

        Network Adapter: Intel(R) Ethernet Connection I219-V
        Interface GUID: {cafa7544-68a7-4145-864c-c5ce5030d1ad}
        NDIS Control State: UnControlled
        NDIS Auth State: UnAuthorized
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Wired-AutoConfig" Guid="{b92cf7fd-dc10-4c6b-a72d-1613bf25e597}" />
        <EventID>15508</EventID>
        <Version>0</Version>
        <Level>4</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime="2019-09-10T20:06:06.168737100Z" />
        <EventRecordID>676</EventRecordID>
        <Correlation />
        <Execution ProcessID="5160" ThreadID="13348" />
        <Channel>Microsoft-Windows-Wired-AutoConfig/Operational</Channel>
        <Computer>T460s-14129.test.org</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="InterfaceGuid">{cafa7544-68a7-4145-864c-c5ce5030d1ad}</Data>
        <Data Name="InterfaceDescription">Intel(R) Ethernet Connection I219-V</Data>
        <Data Name="NdisPortControlState">1</Data>
        <Data Name="NdisPortAuthState">1</Data>
      </EventData>
    </Event>












    ==============  Server Logs  ==============================================================================================

    *****************   Before Unplug the cable: ******************


    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          2019-09-10 4:06:10 PM
    Event ID:      6273
    Task Category: Network Policy Server
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      CERA.test.org
    Description:
    Network Policy Server denied access to a user.

    Contact the Network Policy Server administrator for more information.

    User:
        Security ID:            NULL SID
        Account Name:            50-7b-9d-fd-ce-89
        Account Domain:            test
        Fully Qualified Account Name:    test\50-7b-9d-fd-ce-89

    Client Machine:
        Security ID:            NULL SID
        Account Name:            -
        Fully Qualified Account Name:    -
        Called Station Identifier:        c0-91-34-ff-79-53
        Calling Station Identifier:        50-7b-9d-fd-ce-89

    NAS:
        NAS IPv4 Address:        172.16.X.XXX
        NAS IPv6 Address:        -
        NAS Identifier:            XXXXX
        NAS Port-Type:            Ethernet
        NAS Port:            173

    RADIUS Client:
        Client Friendly Name:        HP Switches
        Client IP Address:            172.16.X.xxx

    Authentication Details:
        Connection Request Policy Name:    Secure Wired (Ethernet) Connections
        Network Policy Name:        -
        Authentication Provider:        Windows
        Authentication Server:        xxx.test.org
        Authentication Type:        MD5-CHAP
        EAP Type:            -
        Account Session Identifier:        -
        Logging Results:            Accounting information was written to the local log file.
        Reason Code:            16
        Reason:                Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
        <EventID>6273</EventID>
        <Version>2</Version>
        <Level>0</Level>
        <Task>12552</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8010000000000000</Keywords>
        <TimeCreated SystemTime="2019-09-10T20:06:10.238983100Z" />
        <EventRecordID>335201692</EventRecordID>
        <Correlation ActivityID="{ad3d4bb8-56cc-0000-5e4d-3dadcc56d501}" />
        <Execution ProcessID="708" ThreadID="14548" />
        <Channel>Security</Channel>
        <Computer>xxx.test.org</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="SubjectUserSid">S-1-0-0</Data>
        <Data Name="SubjectUserName">50-7b-9d-fd-ce-89</Data>
        <Data Name="SubjectDomainName">test</Data>
        <Data Name="FullyQualifiedSubjectUserName">test\50-7b-9d-fd-ce-89</Data>
        <Data Name="SubjectMachineSID">S-1-0-0</Data>
        <Data Name="SubjectMachineName">-</Data>
        <Data Name="FullyQualifiedSubjectMachineName">-</Data>
        <Data Name="CalledStationID">c0-91-34-ff-79-53</Data>
        <Data Name="CallingStationID">50-7b-9d-fd-ce-89</Data>
        <Data Name="NASIPv4Address">172.16.x.xxx</Data>
        <Data Name="NASIPv6Address">-</Data>
        <Data Name="NASIdentifier">Closet6_SW2</Data>
        <Data Name="NASPortType">Ethernet</Data>
        <Data Name="NASPort">173</Data>
        <Data Name="ClientName">HP Switches</Data>
        <Data Name="ClientIPAddress">172.16.x.xxx</Data>
        <Data Name="ProxyPolicyName">Secure Wired (Ethernet) Connections</Data>
        <Data Name="NetworkPolicyName">-</Data>
        <Data Name="AuthenticationProvider">Windows</Data>
        <Data Name="AuthenticationServer">xxxx.test.org</Data>
        <Data Name="AuthenticationType">MD5-CHAP</Data>
        <Data Name="EAPType">-</Data>
        <Data Name="AccountSessionIdentifier">-</Data>
        <Data Name="ReasonCode">16</Data>
        <Data Name="Reason">Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.</Data>
        <Data Name="LoggingResult">Accounting information was written to the local log file.</Data>
      </EventData>
    </Event>




    *****************   After plug the cable: ******************

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          2019-09-10 4:06:24 PM
    Event ID:      6272
    Task Category: Network Policy Server
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      xxx.test.org
    Description:
    Network Policy Server granted access to a user.

    User:
        Security ID:            test\T460S-14129$
        Account Name:            host/T460s-14129.test.org
        Account Domain:            test
        Fully Qualified Account Name:    test\T460S-14129$

    Client Machine:
        Security ID:            NULL SID
        Account Name:            -
        Fully Qualified Account Name:    -
        Called Station Identifier:        c0-91-34-ff-69-00
        Calling Station Identifier:        50-7b-9d-fd-ce-89

    NAS:
        NAS IPv4 Address:        172.16.x.xxx
        NAS IPv6 Address:        -
        NAS Identifier:            Closet6_SW2
        NAS Port-Type:            Ethernet
        NAS Port:            173

    RADIUS Client:
        Client Friendly Name:         HP Switches
        Client IP Address:            172.16.x.xxx

    Authentication Details:
        Connection Request Policy Name:    Secure Wired (Ethernet) Connections
        Network Policy Name:        Secure Wired & Wireless (Ethernet) Connections
        Authentication Provider:        Windows
        Authentication Server:        xxx.test.org
        Authentication Type:        PEAP
        EAP Type:            Microsoft: Secured password (EAP-MSCHAP v2)
        Account Session Identifier:        -
        Logging Results:            Accounting information was written to the local log file.

    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
        <EventID>6272</EventID>
        <Version>2</Version>
        <Level>0</Level>
        <Task>12552</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8020000000000000</Keywords>
        <TimeCreated SystemTime="2019-09-10T20:06:24.118399000Z" />
        <EventRecordID>335201964</EventRecordID>
        <Correlation ActivityID="{ad3d4bb8-56cc-0000-5e4d-3dadcc56d501}" />
        <Execution ProcessID="708" ThreadID="4364" />
        <Channel>Security</Channel>
        <Computer>CERA.test.org</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="SubjectUserSid">S-1-5-21-1085031214-1326574676-839522115-44615</Data>
        <Data Name="SubjectUserName">host/T460s-14129.test.org</Data>
        <Data Name="SubjectDomainName">test</Data>
        <Data Name="FullyQualifiedSubjectUserName">test\T460S-14129$</Data>
        <Data Name="SubjectMachineSID">S-1-0-0</Data>
        <Data Name="SubjectMachineName">-</Data>
        <Data Name="FullyQualifiedSubjectMachineName">-</Data>
        <Data Name="CalledStationID">c0-91-34-ff-69-00</Data>
        <Data Name="CallingStationID">50-7b-9d-fd-ce-89</Data>
        <Data Name="NASIPv4Address">172.16.x.xxx</Data>
        <Data Name="NASIPv6Address">-</Data>
        <Data Name="NASIdentifier">Closet6_SW2</Data>
        <Data Name="NASPortType">Ethernet</Data>
        <Data Name="NASPort">173</Data>
        <Data Name="ClientName"> HP Switches</Data>
        <Data Name="ClientIPAddress">172.16.X.X</Data>
        <Data Name="ProxyPolicyName">Secure Wired (Ethernet) Connections</Data>
        <Data Name="NetworkPolicyName">Secure Wired &amp; Wireless (Ethernet) Connections</Data>
        <Data Name="AuthenticationProvider">Windows</Data>
        <Data Name="AuthenticationServer">XXX.test.org</Data>
        <Data Name="AuthenticationType">PEAP</Data>
        <Data Name="EAPType">Microsoft: Secured password (EAP-MSCHAP v2)</Data>
        <Data Name="AccountSessionIdentifier">-</Data>
        <Data Name="LoggingResult">Accounting information was written to the local log file.</Data>
      </EventData>
    </Event>


    • Edited by Sasit Tuesday, September 10, 2019 8:49 PM
    Tuesday, September 10, 2019 8:20 PM
  • Hi,

    Thanks for your posting.

    I have looked over the log you provided. I notice a question, please take a look at the highlight of the following picture. We can find that the authentication user credentials of unplugging the cable and plugging the cable are different. Before unplug the cable, the client provide MAC address to authenticate. It is very strange.

    Could you post the configuration of 802.1x on client?

    Best regards,

    Hollis



    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Wednesday, September 11, 2019 9:31 AM
  • Hi,

    Thank you helping on this issue, here is our client settings; (my account not yet verified and not able to upload the images)

    Authentication-->

    "Enable IEEE 802.1X authentication" and Microsoft Protected EAP (PEAP) selected,

    "Remember my credentials for this connection each time I'm logged on" not selected

    "Fallback on unauthorized network access" selected

    PEAP Properties -->

    "Verify the sever identity by validating the certificate" selected

    "Authentication method secured EAP-MSCHAP V2 "  & Enable fast reconnect ticked

    Advanced setting -->

    Specify authentication mode -> Computer authentication

    Wednesday, September 11, 2019 12:58 PM
  • I use the same config as Sasit above just without the Verify PEAP property and user authentication instead of computer.

    I can not provide you the NPS logs at this time. I can provide you with some Wired Auto Config Errors if you believe they would be helpful. I have noticed that the Desktops that are affected more frequently with this problem are HP AIO ones so there may be a network card issue(?). 

    I noticed in your reply to Sasit that during the unplug it changed authentication methods. I can confirm that 8 times out of 10 unplugging and plugging the cable back reconnects to the 802.1x network but i assumed it was because it initiated a new authentication procedure not changing from mac to user like you suggested in your reply to Sasit. Also opening the Properties and re-entering the credentials connects to the network. The problem is that it doesn't always keep them apparently. And that it is not consistent. Some days there are no problem some others there are plenty.In some rare cases the network might be lost even during the day.  When i get the logs i will get back to you unless you find a solution for Sasit that also covers me.

    Thursday, September 12, 2019 8:02 AM
  • John Kour, what type on network adapters your machines have? Since Sasit and I have the same Intel I219-V
    Thursday, September 12, 2019 3:57 PM
  • Yes, they are Intel l219-LM on HP AIO machines as well
    • Edited by John Kour Friday, September 13, 2019 6:20 AM
    Friday, September 13, 2019 6:14 AM
  • We have the same issue. Most laptops are Dells with I218-LM or I219-LM. These problem have started since we upgraded to 1903. No such issues were had with 1803.
    Tuesday, September 17, 2019 7:45 PM
  • Any Solution for this Issue ? I got the Same issue and Users unplug network cable or restart the Wired AutoConfig Service, I Updated my NIC to latest drivers and didnt solve issue , this is very Stupid from Microsoft for not testing a critical service like dot1x before issuing a new version
    Thursday, September 19, 2019 10:12 AM
  • Our workaround is restart the WiredAutoconfig service at the system bootup and logon after standby using our desktop management software.

    Friday, September 20, 2019 6:06 PM
  • Am also doing the same restarting the service , but i cannot let the users always do this permanently , did anyone find any solution for this case
    Monday, September 23, 2019 7:33 AM
  • We are having the same issues with 1903 clients.

    We aren't using NPS we use Clearpass to do all the auth work.

    Seeing the same thing where the client supplies it MAC address to the switch and clearpass rejects the auth because of this.

    unpluging network cable/restarting the wired autoconfig fixes the issue until it happens again usually if the PC goes to sleep on next boot up. Client the supplies it hostname to the switch instead of the MAC and gets auth'ed correctly on to network.

    All a pre 1903 on clients seem to be working without any issues.

    Monday, September 23, 2019 9:09 AM
  • Having the same issue with Windows 10 V1903 authenticating against Cisco ISE
    Monday, September 23, 2019 7:46 PM
  • Thanks for the tips everyone. We were able to greatly reduce the occurrence of this issue by deploying a scheduled task that restarts the wired 802.1x service when the computer boots and wakes from sleep via GPP. We set the task's item level targeting to target the Intel NICs using this WMI query

    select * from Win32_NetworkAdapter where productname like '%I21%'

    The task triggers at system startup and also when there is a system event id 1 from System\Microsoft-Windows-Power-Troubleshooter.

    It runs the following command via powershell:

    Restart-Service -Force -Name dot3svc

    Wednesday, September 25, 2019 7:55 PM
  • So basically you are unplugging & plugging with a task. That's nice thank you for sharing theothersnowden :)

    Although others have mentioned it didn't work for them, manually updating network adapter drivers to the latest version seems to work for us for a couple of days now. If it fails again i will try your solution. And i agree with jaimie all pre 1903 machines work fine untill they get updated. 

    Thursday, September 26, 2019 5:12 AM
  • Actually making a scheduled task for restarting a service is just a workaround and not fixing the root cause why is this happening , and i wonder why didn't Microsoft till now announce this issue as a bug in 1903.

    @john kour i updated all of the Drivers on those pcs and still having the same issue

    Thursday, September 26, 2019 5:55 AM
  • Yeah that is true the workaround is not a solution and it will not work all the time but since microsoft does not offer any help so far, any workaround is appreciated. I was surprised that there were not any threads about this to begin with. Since more people are responding here maybe they notice this issue. It may be a coincidence about the drivers as i mentioned it has only been a couple of days. So far the best thing we can do is lock with mac authentication but that is also a workaround and not a solution.
    Thursday, September 26, 2019 6:13 AM
  • There is an new Version of Intel Driver for NIC I219-LM (maybe also for I218-LM and I217-LM).
    This driver has the Version 24.1 or above. It´s released with Windows 1903.
    You can achieve it directly from the Intel Webiste / Downloadcenter.
    Installing that Driver seemed to work for me (Windows 1903, Intel I219-LM and Authentication with 802.1X)

    Hope it might help you too.

    Cheers

    • Proposed as answer by NB_BRZ Thursday, September 26, 2019 8:32 AM
    • Unproposed as answer by John Kour Friday, November 8, 2019 1:01 PM
    Thursday, September 26, 2019 8:12 AM
  • So now we are two that latest driver seems to be working. Cool!
    Thursday, September 26, 2019 8:22 AM
  • Cool.

    So if you carry on with testing the next time and this is the solution for your issue too, could you please mark my reply as answer?

    Thanks!

    Thursday, September 26, 2019 8:44 AM
  • Yeah no problem, i will wait a few more days but if i encounter no problems and you don't report any problems i will mark it.
    Thursday, September 26, 2019 9:03 AM
  • I tried ver 24.1 and 24.2 which was released a month ago and both didnt solve the problem on my side , its not a driver issue , its a windows issue as this issue happened before in Windows 7 as per this article

    https://support.microsoft.com/en-hk/help/2736878/802-1x-authentication-fails-after-you-connect-a-computer-to-a-network

    Thursday, September 26, 2019 11:18 AM
  • I tried ver 24.1 and 24.2 which was released a month ago and both didnt solve the problem on my side...

    Neither did mine unfortunately.
    Tuesday, October 1, 2019 6:32 PM
  • We having the same issue. If we turn of this: "fallback to unauthorized network acces the PC" than the system logs in perfect. With 1809 build or 802.1x works just fine but with 1903 it doesn't.

    Maybe you can try to turn that checkbox off and try it again. The problem is we can't adjust this setting in the GPO and if we want to do it with netsh we have a problem that the connection is lost because of switching from GPO to import profile with netsh we need to disable the GPO otherwise you can't import a profile.

    We hope there comes a solution fast.

    Thursday, October 3, 2019 8:15 AM
  • I think i had tried that and the result was that the authentication failed and since the pc didn't switch to a free network it was without an internet connection at all. Now this is probably obvious to all but i will mention it anyway. Before you update your network adapter driver you are removing the old ones in order to install the new ones. Most of the times the install wizard asks for it anyway but in some cases it does not so someone may have missed it.
    Thursday, October 3, 2019 8:57 AM
  • I have exact same issues. I have used several days finding cause from network and server side. Comforting that I'm not alone with this one.

    Looking from event log (Applications and Service Logs->Microsoft->Windows->Wired-Autoconfig), seems that OS does not even try to authenticate after cold boot. No problem after disconnecting/connecting LAN-cable or warm boot (restart).

    One of our trouble machines is HP EliteBook 850 G3 with Intel I219-V adapter. Older G2 with Intel I218-LM works just fine. I tried upgrading and downgrading different driver versions but issue persists.

    I would appreciate any ideas what to try next.

    I have seen the same issue in our deployment. After some time I figured out that if you disable fastboot in windows Power & Sleep > Additional Power Settings > Choose what power buttons do > and uncheck the "Turn on fast startup" the issue will resolve itself.

    With fastboot enabled windows will cache the system state on a shutdown and then boot from that image. For whatever reason the dot1x supplicant doesn't initiate in this process. I think it is because dot1x was already initiated when it caches the system state and it simply "resumes" that session. 

    I have only seen this on laptop machines, not sure if this is applicable to desktops.

    Hope that helps.


    Wednesday, October 23, 2019 5:29 PM
  • I noticed this issue a few months ago when i found that some computers were not authenticating after waking from sleep.

    I traced it to KB4501375 and later, so OS Build 18362.207 and later.

    The current intel drivers (24.2) don't help our computers with lntel I219-LM (haven't tested our lntel I217-LM computers).

    I have found the problem to exist on computers with lntel I217-LM and lntel I219-LM, our computers with realtek adapters are unaffected.

    Thursday, October 24, 2019 10:44 AM
  • Hi we have same issue. 

    We have I219-V and I219-LM network card, upgrade driver to 12.18.9.10 and some computer works fine, but many computers doesn't help driver upgrade. 

    Thursday, November 7, 2019 2:33 PM
  • Yes that's the reason i haven't marked it as a solution. Some people see an improvement some not but the problem persists.
    Friday, November 8, 2019 8:20 AM
  • Hi guys,

    we have some other issues since 1903 which may have the same root cause like you guys see in your environment, so I will tell you what we found so far.

    Since we run 802.1X in our company we had the need to allow the users to switch between VLANs form corp intranet to a lab VLAN for example. We wrote a small tool to change auth methods (client certificate, MAC auth, Username, aso.), basically injecting another xml usind "netsh lan add profile". About a week ago some users start to complain they see an error: "Failed to add the profile. A group policy or machine profile already exists and cannot be overwritten." and they can not switch between VLANs any more.

    We also apply the profile for corp intranet on startup using a task in SYSTEM conext, which may saved our butts accidentally. When this task kicks in, a machine profile for 802.1X is created that seems to apply to all wired adapters (C:\ProgramData\Microsoft\dot3svc\Profiles\Machine). You do not see the "Machine" folder on older builds. Also "netsh lan show profiles" is listing a "MachinProfile" which also does not show up on older Win 10 versions. If no MachineProfile is there, also the Authentication tab is missing on the NICs properties.

    We found no relations to driver versions or make and model of the NICs yet, but we just started our analysis.

    I can post updates on our progress here if someone is interested.

    regards

    --Marc--

    Sunday, November 10, 2019 3:50 PM
  • Yes, it would be nice if you could keep us updated. Now regarding the NIC most of us who experience this problem use the ones mentioned above. Machines with different ones do not seem to be affected by this issue.
    Monday, November 11, 2019 1:04 PM
  • Hi everybody. 

    We are experiencing the same problem with our 802.1x network and ours Windows 10 1903 (build 18362.469) since we deployed the KB4522355. 

    I noticed that the "dot3svc" service do not start correctly when you shutdown a PC, i foudn it was due to a Windows 10 feature called "Fast Startup. We disabled this feature via GPO by changing the value of the registry key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled" to 0 and now PCs are connecting to the network at startup. 

    That explain why we do not have the problem when restarting PCs, because rebooting a PC also rebooting services. 

    I also open a case at Microsoft support. 

    Hope it help.

    Guillaume. 


    • Edited by G. Murgier Wednesday, November 20, 2019 2:58 PM
    Wednesday, November 20, 2019 2:54 PM
  • i have already change this registry key on my computer and the problem is still. 
    Thursday, November 21, 2019 6:42 AM
  • Any news?
    Thursday, November 28, 2019 7:46 PM
  • I'm still waiting for Microsoft to give me a solution to this issue. They still investigate. 

    Friday, November 29, 2019 9:27 AM
  • We have had the same problem since update 1903.
    The problem is intermittent, the same computer / user can sometimes authenticate and obtain IP, other times can only have network if you restart the computer.
    Stopping and starting the service does not work.
    Removing and attaching the network cable does not work.

    The error I get in the event viewer is:

    Wired 802.1X Authentication failed.

    Network Adapter: Realtek PCIe GBE Family Controller
    GUID interface: {72f99c82-2e1e-4a98-96ee-85149c00b238}
    Peer Address: 000000000000
    Local Address: 7CD30A2968E9
    Connection ID: 0x1
    Identity: -
    User: -
    Domain: -
    Reason: 0x50001
    Reason Text: Unable to Identify a User for 802.1X Authentication
    Error Code: 0x525

    Even after the 1909 update the problem remains.

    Every help is welcome.

    Thank you.
    • Edited by dio33 Tuesday, December 3, 2019 5:25 PM
    Tuesday, December 3, 2019 5:25 PM
  • I have the same problem as you, when I go to the logs I get the same error, has anyone been able to solve the problem? , because from what I see Microsot no.
    Monday, December 9, 2019 5:40 PM
  • We have the exact same problem where the computer uses the MAC as accountname when trying to authenticate after hibernation.

    It seems the problem is only related to I219-V cards in our environment.

    We tried:
    -Updating NIC driver
    -Upgrading to 1909

    Disabling power saving on the NIC seems to have solved the problem.. (have to test more)



    Wednesday, December 11, 2019 10:34 AM
  • Any Solution for this Issue ? I got the Same issue with 1909 clients
    Monday, December 30, 2019 9:07 AM
  • We also have the same issue. 

    I've noticed this event log, any relation with this issue?

    LogName: Microsoft-Windows-Wired-AutoConfig/Operational

    Source: Wired-AutoConfig

    Event ID:  15501

    The network adapter has been unplugged.

     Network Adapter: Intel(R) Ethernet Connection I219-LM
     Interface GUID: {532b18a1-4e10-4d2e-a29c-d8100aa11bf2}

    then 

    The network adapter has been connected.

     Network Adapter: Intel(R) Ethernet Connection I219-LM
     Interface GUID: {532b18a1-4e10-4d2e-a29c-d8100aa11bf2}

    Anybody did troubleshooting with below article?

    https://docs.microsoft.com/en-us/windows/client-management/advanced-troubleshooting-802-authentication

    Tuesday, January 21, 2020 10:19 AM
  • Hi everybody,

    after a long investigation with MSFT it seem that the problem come from the Intel Driver NDIS 6.8. 

    "Intel may need to check if their Driver NDIS6.8 Intel Pro 1000 is fully compatible with Fast startup mode. Are they aware of similar issue ? Issue is long transition time from state D3 to D0 (OID_PNP_SET_POWER) for their NDIS 6.8 driver."

    "What we could see is that after upgrade the driver on the NIC is new and it is using NDIS68 (information visible as well from readme on the latest driver)."

    So reeinstalling the NDIS 6.5 driver could solve the issue. 

    Did someone here already contacted Intel about this Issue ? I'll try to contact them.

    Friday, January 24, 2020 8:41 AM
  • There is a lot of confusion in this thread.  It appears as if Microsoft is being blamed for old or bad hardware drivers.  Microsoft will not, does not and will never write driver software.  Whatever issues are present will need to be solved by the manufacturer.

    Look to the manufacturer for driver updates and fixes.  If you spend more than 15 seconds paying attention to this thread, buy a $10 replacement adapter, install the manufacturers latest driver and be done with it.

    The default Microsoft drivers have been known to cause huge issues of all kinds with Intel cards.  Especially when systems go to sleep, they broadcast ipv6 packets to other computers consuming all network bandwidth.


    Saturday, January 25, 2020 5:01 AM
  • @gettnmorebetter : do you really thing peoples who are contacting Microsoft are experiencing the issue in one machine ? Some of the people here probably have undred or thousand machines (like me) under there responsability. The problem appear right after an update so contacting Microsoft or searching a problem in the operating system is the first step. 

    No one has blamed the default driver, the problem is also present with the last Official Intel driver and only in Windows 1903 or newer. 

    Monday, January 27, 2020 7:49 AM
  • Hi everybody,

    i just get an answer from intel, they are aware of the issue and will fix this in a future driver release. 

    "Thank you for the information, it seems we have a few cases like this so far. There is an ongoing investigation for this issue with no results so far.

    Most likely this will be fixed with a new driver release, in the meantime you can try using the workaround suggested in the microsoft post, setting up a windows schedule to reset the service (workaround). "

    I closed my case at Microsoft support because the problem is now clearily identify as a driver issue. 

    Thursday, January 30, 2020 10:43 AM
  • I've had the same problem on build 1903 and 1909 with a Intel(R) Ethernet Connection I217-LM adapter.

    Disabling Hiberboot fixed the problem.

    Tuesday, February 4, 2020 9:30 AM
  • Adapter: Intel I219-LM

    Intel Drivers: 12.18.9.10

    Windows Version: 1809

    Hiberboot: disable

    Issue not solved.

    Any more tips?

    Thanks

    Tuesday, February 18, 2020 10:40 AM
  • Adapter: Intel I219-LM

    Intel Drivers: 12.18.9.10

    Windows Version: 1809

    Hiberboot: disable

    Issue not solved.

    Any more tips?

    Thanks

    Hi, you can try this in addition to disabling Fast Startup : go to "Device Manager", select your network adapter and in the tab "power management" uncheck "allow the computer to turn off this device to save power". 

    It's seem that the problem come from the fact that operating system do not wake up devices in the normal way. 

    Monday, February 24, 2020 2:35 PM
  • Adapter: Intel I219-LM

    Intel Drivers: 12.18.9.10

    Windows Version: 1809

    Hiberboot: disable

    Issue not solved.

    Any more tips?

    Thanks

    Hi, you can try this in addition to disabling Fast Startup : go to "Device Manager", select your network adapter and in the tab "power management" uncheck "allow the computer to turn off this device to save power". 

    It's seem that the problem come from the fact that operating system do not wake up devices in the normal way. 

    Thank you! i add your tip to my mitigation steps.

    This dont solve the problem 100%, but help in most of the issues cases.

    Mitigation steps, hopes this can help.

    Step 1

    Update to latest existing driver

    Step 2

    Disable hiberboot
    https://www.tenforums.com/tutorials/4189-turn-off-fast-startup-windows-10-a.html

    Step 3

    Windows 8/10 Registry Changes for 802.1x Authentication

    1. Press the Windows logo Key+R to open the Run box.

    2. Type regedit in the Run box, and then press Enter.

    3. Locate and then select the following registry subkey:

                    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

    4. On the Edit menu, click New, and then click DWORD (32-bit)

    5. Type LsaAllowReturningUnencryptedSecrets, and then press Enter.

    6. Right-click LsaAllowReturningUnencryptedSecrets, click Modify…, type 1 in the Value data box, and then click OK.

    7. Exit Registry

    https://docs.microsoft.com/en-us/windows/win32/secauthn/lsa-authentication

    https://docs.microsoft.com/en-us/windows/win32/secauthn/lsa-authentication-model

    Step 4

    "Device Manager", select your network adapter and in the tab "power management" uncheck "allow the computer to turn off this device to save power". 

    Thanks!

    • Edited by Zé Tó Friday, February 28, 2020 10:58 AM
    Friday, February 28, 2020 10:57 AM
  • Hi Guillaume,

    did you get any further information from Intel?

    I have a case open with MS. They checked logs showing the NIC driver (also tested latest 25.0) is causing the 802.1x issue.

    Thanks

    Michael


    Tuesday, March 10, 2020 1:11 PM
  • Hi Mickael, 

    i get an answer from Intel yesterday and there is no good news... The Intel's engineering team didn't find anything wrong with their driver.

    They advised me to mitigate the issue with the solution i provided above : disable fast startup et uncheck powersaving on the NIC.

    I dont have anymore solution right now so i'll try my best to mitigate the issue by myself. 

    You will find the solution they provided to me below (in my case this didn't help) :

    "I apologize again for the delay in my answering, I was expecting updates from our engineering team. They have reviewed all our latest Intel Ethernet Drivers and they do not seem to find any Driver limitation over the Fast StartUp or Power Consumption State in Device Manager. I also checked a new article from Microsoft on Windows 10 devices that are not able to connect to 802.1x Network environments.

    Did you already have the chance to consult it as well and check this with your Network Environment Administrator?: https://support.microsoft.com/en-gb/help/3121002/windows-10-devices-can-t-connect-to-an-802-1x-environment

    Also, here is an article on System Power States and WOL as well from Microsoft: https://docs.microsoft.com/en-us/windows/win32/power/system-power-states In the above article, we have the following information: WOL is not officially supported from soft off (S5). However, the BIOS on some systems may support arming NICs for wake, even though Windows is not involved in the process. WOL is supported from sleep (S3) or hibernate (S4). It is not supported from fast startup or soft off (S5) shutdown states. As I see, also Microsoft has declared that WOL is not supported on Fast StartUp and we also think that the Operating System is not being involved in this process and that might be the issue as well in your situation. My suggestion would be to check the first article as well and check with your Network Administrator if it would be possible to perform the updates and changes suggested by Microsoft in that article for your Company Network."

    If I find anything I will come and put it here

    Wednesday, March 11, 2020 3:25 PM
  • Have you turned on the auditing for NPS, and if so, can you share the text of the 'audit fail' event (redacting any sensitive information first, of course?)

    Edit 1: The referenced group policy setting is Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff -> Audit Network Policy Server.

    Edit 2: This will allow you to view logon successes and failures (and compare the differences for that '1 out of 10' that works. You'll find the log in Event Viewer at Custom Views\Server Roles\Network Policy and Access Services

    Edit 3: (and hopefully the final one:) The breakthrough that let me find this was that I went on a client, deleted the 512-bit ecdh based cert and used the old, original, insecure default certificate template. The NPS server started accepting it, so I started creating new templates, changing one variable at a time until I found out it was the jump to 512-bit that broke it.
    Wednesday, March 18, 2020 5:07 PM
  • Hi there,

    Wanted to start implementing the NAS in my environement, did "everything" I was supposed to do on a Cisco SG500 and started struggling... ;-)

    So my test device is a notebook (Win10 1909 - DEll E6400), all certificates are automatically deployed by GPO and wireless is working flawlessly since years with the NPS.

    I've tried all tricks above but none of them solved the issue.

    What makes me able to authenticate without changing anything (switch, NPS, port settings) is to quickly authenticate with wireless, then put the cable back in the laptop and then it goes perfectly (even reconnect works).

    It might be a different issue but it is arround the same area... I wanted to share my findings.

    What I've seen also so far, when I reboot, I don't see any auth log on the NPS. It's like 802.1X is not passed along.
    In Windows I see events 15014 with reason 0x50006

    Any proposition ? :-)

    Friday, April 3, 2020 10:12 AM