none
Black Screen Explorer.exe crash with Roaming Profiles. When roaming from 1803 to 1709. RRS feed

  • Question

  • Hi,

    We have an issue with roaming profiles and users roaming from our 1803 labs to our 1709 labs.  A user logs in to 1803 ok and logs off. Their profile.v6 is stored on network storage and path is defined on the users AD account. The user then roams to a 1709 machine.  Upon login the user is greeted with a black screen which never disappears and and event viewer logs:

    Log Name:      Application
    Source:        Application Error
    Event ID:      1000
    Description:
    Faulting application name: Explorer.EXE, version: 10.0.16299.637, time stamp: 0xd1134b58
    Faulting module name: Windows.CloudStore.dll, version: 10.0.16299.98, time stamp: 0xd9fb8a36 

    At this point the user can ctrl+alt+del and sign out and log back in to the 1709 successfully or Task manager > Run new task. Type explorer.exe, and then select Ok.

    The profile will continue to work ok but the issue is immediately reproduced as soon as they roam to an 1803 machine and log back in to a 1709 machine.  It always happens on the fist login on a 1709 machine after logging in to an 1803 machine.

    All of our labs are on Win 10 Education.  We have the "disable sign-in animation" GPO set and we configure SpecialRoamingOverrideAllowed in the registry on the clients.  If I re-enable the sign in animation, instead of the black screen I just get the sign in animation permanently on loop for 15 mins.

    If I repeat this test on a freshly installed 1803 machine with no windows updates installed the issue does not occur.  If I apply windows updates (up to 2018-10 Cumulative update for 1803) the issue occurs.  1 other university we know has been able to reproduce this issue and is currently holding back on deploying 1803 because of it.

    Cheers,

    Steve







    • Edited by Steve_23 Thursday, November 22, 2018 3:57 PM
    Tuesday, November 20, 2018 9:48 AM

Answers

  • I've done some testing today with the May updates installed.

    I added the following reg entry to my 1803 and 1709 machine:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ProfSvc\Parameters]
    "UseProfilePathMinorExtensionVersion"=dword:00000001

    1709 started using profile.v6.2

    1803 started using profile.v6.3

    and 1809 remained using profile.v6 (as expected as no reg change had been made)

    The black screen issue is fixed on machines with this configuration, as each version of Win 10 has its own separate profile.  Whether this is a desirable configuration for our environment and users remains to be seen.

    Cheers.


    Steve Keele University UK



    • Marked as answer by Steve_23 Thursday, May 23, 2019 11:10 AM
    • Edited by Steve_23 Thursday, May 23, 2019 11:11 AM
    Thursday, May 23, 2019 11:09 AM
  • After an internal conversation it has been confirmed that it is a bug, and a new update will be published in April 2019, no specific date

    Regards

    • Marked as answer by Steve_23 Wednesday, March 13, 2019 12:02 PM
    Tuesday, March 12, 2019 12:56 PM

All replies

  • Hi Steve,

    Thanks for posting your query.

    Is there any dump file in your C:\? 

    1. To troubleshoot whether the issue is related to a third party service, please check the symptom in a clean boot environment.

    https://support.microsoft.com/en-us/help/929135/how-to-perform-a-clean-boot-in-windows

    2. Please run command as an administrator and type: sfc /scannow to fix system component. 

    3. It would be better to access Windows Recovery mode to make system repair.

    4. If the issue occurs after installing the 2018-10 Cumulative update, Please wait for the next update for Windows 10 and install them together and check if the issue will be solved.

    Best regards,

    Yilia 


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


    Wednesday, November 21, 2018 7:57 AM
    Moderator
  • Hi,

    Is there anything I can do for you?

    If you have any problems or concerns, please feel free to post here. 

    Best regards,

    Yilia



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

    Friday, November 23, 2018 1:39 AM
    Moderator
  • Hi Yilia,

    I have installed a fresh copy of 1803 and 1709 on my test machines and completed windows updates up to 2018-10.  I put both in a clean boot state following the advice in the article you mentioned.  The machines have no applications or third party software installed at all.  The error reproduces in exactly the same way.  As this is also happening at other universities and is happening with no third party software or services running, I think this bug will be reproducible in your test environments.

    Would you like me to run sfc /scannow in recovery mode or is this test now not needed as I did a fresh install from install media on both?

    I can try with the 2018-11 updates applied on both?

    Cheers,

    Steve


    Steven Keele University UK


    • Edited by Steve_23 Friday, November 23, 2018 11:27 AM
    Friday, November 23, 2018 11:26 AM
  • Hi,

    Thanks for your reply.

    Run scf /scannow in normal mode and it will fix system files automatically. 

    If you install the 2018-11 updates, it will help you solve known issues that were previously updated. Just install the latest updates in issue machine and check if the issue be solved. Please type Check for updates in search box and install them. 

    If the issue still occurs, we need to uninstall 2018-10 Cumulative update for 1803.

    Best regards,

    Yilia 


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

    Monday, November 26, 2018 9:36 AM
    Moderator
  • We're also seeing the same issue (black screen on login) on 1709 when roaming from either 1803 or 1809. 

    Thursday, November 29, 2018 2:40 PM
  • Hi Yilia,

    Results from my tests:

    Both machines were in a clean boot state throughout.

    1. SFC /scannow on 1803 and 1709 machine: no Integrity violations. Same black screen issue (tried with profile reset too)
    2. Install 2018-11 on both machines: Same black screen issue (tried with profile reset too)

    3. Uninstall 2018-11 and 2018-10 on both machines: Same black screen issue (tried with profile reset too)

    4. Uninstall 2018-09 on both machines: Same black screen issue (tried with profile reset too)

    5. Uninstall all uninstallable win updates (some flash updates had installed): Same black screen issue (tried with profile reset too)

    I don't appear to be able to get the 1803 machine back to its original freshly installed state where the issue wasn't happening.  There are some updates that I cannot uninstall though:

    Can this issue be escalated and investigated your end?  I'm pretty sure any vanilla MS roaming profile environment should be able to reproduce this issue.

    Cheers,

    Steve


    Steven Keele University UK







    • Edited by Steve_23 Friday, November 30, 2018 8:59 AM
    Thursday, November 29, 2018 2:42 PM
  • Another one here. We can't roam from 1803 to 1709 without the black screen issue. We're seeing it across our entire estate and have had to put rollout of 1803 on hold because of it.

    Faulting module name: Windows.CloudStore.dll, version: 10.0.16299.98, time stamp: 0xd9fb8a36

    Exception code: 0xc0000409

    Fault offset: 0x0000000000074dee

    Faulting process id: 0x2140

    Faulting application start time: 0x01d44f22d778741a

    Faulting application path: C:\Windows\Explorer.EXE

    Faulting module path: C:\Windows\System32\Windows.CloudStore.dll

    Report Id: d5057f5f-9809-49cc-ac0e-20ccba7ed808

    Faulting package full name:

    Faulting package-relative application ID:

    Thursday, November 29, 2018 2:48 PM
  • Hi Yilia,

    Any news on this?

    Cheers,

    Steve


    Steven Keele University UK


    • Edited by Steve_23 Thursday, December 20, 2018 9:32 AM
    Tuesday, December 18, 2018 3:02 PM
  • Hi Steve,

    Sorry for the delay reply.

    For further help, I suggest you submit a new case on Directory Service forum as they will be more professional on your issue:
    This is the Directory Service forum link:

    https://social.technet.microsoft.com/Forums/en-US/home?forum=winserverDS

    Since we considered this issue would be a potential issue, we can use Windows 10 built-in feedback hub (type feedback hub in search box) to give Microsoft a valuable feedback and I am going to submit this case to Microsoft via our channel. 

    Best regards,

    Yilia 


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



    Wednesday, December 19, 2018 1:57 AM
    Moderator
  • Hi Yilia/Moderators

    Can this post be moved to the Directory Service forum so the testing and communication that has taken place so far is retained?

    Cheers,

    Steve


    Steven Keele University UK


    • Edited by Steve_23 Thursday, December 20, 2018 9:32 AM
    Thursday, December 20, 2018 9:31 AM
  • Hi Steve,

    I'm sorry for that after confirmed with Directory Service Engineer, it seems to be a potential issue. We need to waiting for next update and install them together, then check if it will be solved.

    As mentioned above, we also can use Windows 10 built-in feedback hub (type feedback hub in search box) to give Microsoft a valuable feedback and I am going to submit this case to Microsoft via our channel.

    You could contact Microsoft Support for further help through the link below:

    https://support.microsoft.com/en-us/contactus/windows/tech-services/?productId=100110237&issueId=100110238&subIssueId=100110239

    Best regards,

    Yilia 


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

    Friday, December 21, 2018 9:19 AM
    Moderator
  • Hello Yilia,

    Any update on this problem that you are aware of?

    Thanks!


    Wednesday, January 30, 2019 7:16 PM
  • Yilia,

    Just to confirm that 1809 is also broken roaming to 1709. Both machines up to date with January patch sets. Same error with explorer crashing on 1709:

    Faulting application name: Explorer.EXE, version: 10.0.16299.637, time stamp: 0xd1134b58
    Faulting module name: Windows.CloudStore.dll, version: 10.0.16299.98, time stamp: 0xd9fb8a36
    Exception code: 0xc0000409
    Fault offset: 0x0000000000074dee
    Faulting process ID: 0x1b7c
    Faulting application start time: 0x01d4bd37f8fd315b
    Faulting application path: C:\Windows\Explorer.EXE
    Faulting module path: C:\Windows\System32\Windows.CloudStore.dll
    Report ID: 34542ccf-c289-4b04-b4da-8903c6c62522
    Faulting package full name:
    Faulting package-relative application ID:

    Tuesday, February 5, 2019 9:56 AM
  • Hi Yillia, has there been any progress on this from Microsoft? We are also getting the same error. Is there an update to fix this?

    Faulting application name: Explorer.EXE, version: 10.0.16299.15, time stamp: 0x66e02565
    Faulting module name: Windows.CloudStore.dll, version: 10.0.16299.15, time stamp: 0x39300de4
    Exception code: 0xc0000409
    Fault offset: 0x0000000000074e2e
    Faulting process id: 0x1af8
    Faulting application start time: 0x01d4becc3db11c93
    Faulting application path: C:\Windows\Explorer.EXE
    Faulting module path: C:\Windows\System32\Windows.CloudStore.dll
    Report Id: 90d76e8e-d580-40dc-a829-9f72076ba6c0
    Faulting package full name: 
    Faulting package-relative application ID: 

    Thanks.

    Thursday, February 7, 2019 10:18 AM
  • We too have had to put our upgrades on hold until this is resolved.  The only downside is we are approaching the "cut-off" for 1709.  Any updates/help from Microsoft's side would be greatly appreciated.

    Cheers,

    Rusty

    Wednesday, February 13, 2019 4:56 PM
  • Hi,

    Is it possible to have an update on this issue?  As far as I'm aware Roaming Profiles are still supported:

    https://docs.microsoft.com/en-us/windows-server/storage/folder-redirection/deploy-roaming-user-profiles

    1709, 1803 and 1809 have been designed by MS to share profile.v6, so this should be investigated and fixed?

    Cheers,

    Steve


    Steve

    Keele University 

    • Edited by Steve_23 Thursday, February 21, 2019 8:48 AM
    Thursday, February 21, 2019 8:47 AM
  • Hi,

    About this issue, a customer found that this registry key on Windows 10 build 1803 have the value of 1

    HKCU\Software\Microsoft\Windows\CurrentVersion\StartLayout\Migration

    IsTransformerDataMigrated = dword:00000001

    If before logoff you change the value to 0 and logon on Windows 10 build 1709 the system works without black screen

    Tuesday, February 26, 2019 1:29 PM
  • Thanks for sharing this Victor.

    I can confirm that IsTransformerDataMigrated is set to 1 when logging on to 1803 and 1809 and setting it to 0 before log off stops the black screen happening on the 1709 machine.

    I've noticed that when the 1709 machine black screens it sets IsTransformerDataMigrated to 0 during the black screen logon (so the next 1709 login, logs in ok).

    IsTransformerDataMigrated is not documented anywhere from what I can see.  I'm interested in knowing the ramifications of manipulating this registry value at logoff/logon on 1709/1803/1809 machines and if this is an acceptable workaround to use?  What do you think Microsoft?

    • Edited by Steve_23 Wednesday, March 6, 2019 4:03 PM
    Thursday, February 28, 2019 2:03 PM
  • Hi Steve,

    It seems that there is no problem in using that registry key and in addition Microsoft is working on a Fix.

    Yes, this is an acceptable workaround

    I will receive more information next week

    Regards


    • Edited by realpc2008 Friday, March 1, 2019 1:29 PM
    Friday, March 1, 2019 1:28 PM
  • That key seems to be working for us, too.

    Some interesting observations on it. I can't get new profiles to create that key on 1709, nor can I get it to be created when roaming between 1709s. I also don't get the key when roaming from 1607 to 1709.

    One earlier thing we spotted was user mode crash dumps from when explorer crashes during the logon to 1709 with that key set to 1 indicate a failed call to an entry point in ntdll.dll that doesn't exist.

    This is pure conjecture, but I'm guessing some code intended only for 1803 and up has leaked into 1709 during an update and is responding to the key being present then crashing out because it's incompatible with 1709 (hence the missing entry point call).

    If anyone manages to get that key to pop up in 1709 under any conditions other than having roamed in from 1803 and upwards please post as it will have a real bearing on how we approach this as a workaround.


    • Edited by hal18ut Monday, March 4, 2019 10:40 AM
    Monday, March 4, 2019 10:39 AM
  • After an internal conversation it has been confirmed that it is a bug, and a new update will be published in April 2019, no specific date

    Regards

    • Marked as answer by Steve_23 Wednesday, March 13, 2019 12:02 PM
    Tuesday, March 12, 2019 12:56 PM
  • Excellent news Victor!  Thank you for the update.

    Steve Keele University UK


    • Edited by Steve_23 Wednesday, March 13, 2019 12:02 PM
    Wednesday, March 13, 2019 12:01 PM
  • FYI I have just tested the April updates thus far and the bug is still present. 

    Steve Keele University UK


    • Edited by Steve_23 Friday, April 12, 2019 1:16 PM
    Friday, April 12, 2019 1:15 PM
  • This released yesterday - https://support.microsoft.com/en-gb/help/4493440/windows-10-update-kb4493440 - but for 1709 and 1803 only. The "fix" is described as "Addresses an issue that causes a roaming profile user to lose customized Start menu settings after upgrading the operating system (OS). After installing this update, administrators must enable the UseProfilePathMinorExtensionVersion registry setting described in KB4493782 for roaming user profiles (RUP). This key allows you to create a new RUP for an upgraded OS and prevents the loss of a custom Start menu. The RUP must be stored locally, and you must restart the device to enable the feature." within this update - which doesn't seem to match the issue described here. We are testing this....

    Friday, April 26, 2019 8:35 AM
  • I have installed the latest April updates for my 1803 and 1709 test machine and can confirm that the issue is still present.  Any idea when this will be fixed?  Cheers.

    Steven Keele University UK


    • Edited by Steve_23 Thursday, May 2, 2019 8:42 AM
    Thursday, May 2, 2019 8:42 AM
  • Steve,

    Can you confirm that you have the specific update (kb4493440) installed and made the mentioned registry changes?  SCCM hasn't pulled the update down yet for me.  The latest I see is  KB4493441.  When I get some free time, I'll try and test with two machines.

    Cheers!

    Wednesday, May 8, 2019 7:04 PM
  • I've done some testing today with the May updates installed.

    I added the following reg entry to my 1803 and 1709 machine:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ProfSvc\Parameters]
    "UseProfilePathMinorExtensionVersion"=dword:00000001

    1709 started using profile.v6.2

    1803 started using profile.v6.3

    and 1809 remained using profile.v6 (as expected as no reg change had been made)

    The black screen issue is fixed on machines with this configuration, as each version of Win 10 has its own separate profile.  Whether this is a desirable configuration for our environment and users remains to be seen.

    Cheers.


    Steve Keele University UK



    • Marked as answer by Steve_23 Thursday, May 23, 2019 11:10 AM
    • Edited by Steve_23 Thursday, May 23, 2019 11:11 AM
    Thursday, May 23, 2019 11:09 AM
  • Well, that's not very hopeful.  I was hoping that this would be patched and fixed in an update.  So, to be clear - Setting that registry setting requires double the amount of storage, right?  One copy for 1709 and one for 1803, and so on..?

    We are at the point where we might just have to put in our own ticket with Microsoft.  

    Monday, June 24, 2019 2:07 PM
  • Yeah, if splitting the roaming profiles out is the official fix it seems like a junk solution. I'm not waiting for a MS fix anymore though; I'm going with the registry hack mentioned above in a Powershell logoff script, targeted at the upgraded machines by a gpo with a wmi filter.  Seems to work, and once all machines are upgraded the script can be removed.
    Monday, July 8, 2019 10:52 AM
  • Thanks guys for this thread, and especially Steve.

    Hadn't occurred to me before to target only old versions for the split profiles and leave current versions at .v6, but that seems a decent way to handle it, so that we're only fixing users of old builds and not necessarily everyone.

    For anyone interested, this link details how to target specific builds via GPP - https://kb.policypak.com/kb/article/304-how-can-i-use-item-level-targeting-to-specify-a-specific-windows-10-build-andor-ltscltsb/ . I've used the registry method, and it works well.

    Only real issue for us I think is handling the fact we now have extra profile copies, but we had to do that for the move from .v2 to v6, so it's not really much different I guess. As long as MS want to make functional changes to profiles between versions, I think these issues may be here to stay.

    Thursday, July 11, 2019 11:26 AM