Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, November 20, 2018 9:48 AM
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
All replies (30)
Tuesday, March 12, 2019 12:56 PM ✅Answered
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
Thursday, May 23, 2019 11:09 AM ✅Answered | 1 vote
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
Wednesday, November 21, 2018 7:57 AM
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 [email protected].
Friday, November 23, 2018 1:39 AM
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 [email protected].
Friday, November 23, 2018 11:26 AM
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
Monday, November 26, 2018 9:36 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 [email protected].
Thursday, November 29, 2018 2:40 PM
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:42 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
Thursday, November 29, 2018 2:48 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:
Tuesday, December 18, 2018 3:02 PM
Hi Yilia,
Any news on this?
Cheers,
Steve
Steven Keele University UK
Wednesday, December 19, 2018 1:57 AM
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 [email protected].
Thursday, December 20, 2018 9:31 AM
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
Friday, December 21, 2018 9:19 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：
Best regards,
Yilia
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Wednesday, January 30, 2019 7:16 PM
Hello Yilia,
Any update on this problem that you are aware of?
Thanks!
Tuesday, February 5, 2019 9:56 AM
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:
Thursday, February 7, 2019 10:18 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.
Wednesday, February 13, 2019 4:56 PM
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
Thursday, February 21, 2019 8:47 AM | 1 vote
Hi,
Is it possible to have an update on this issue? As far as I'm aware Roaming Profiles are still supported:
/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
Tuesday, February 26, 2019 1:29 PM | 1 vote
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
Thursday, February 28, 2019 2:03 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?
Friday, March 1, 2019 1:28 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
Monday, March 4, 2019 10:39 AM
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.
Wednesday, March 13, 2019 12:01 PM
Excellent news Victor! Thank you for the update.
Steve Keele University UK
Friday, April 12, 2019 1:15 PM
FYI I have just tested the April updates thus far and the bug is still present.
Steve Keele University UK
Friday, April 26, 2019 8:35 AM
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....
Thursday, May 2, 2019 8:42 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
Wednesday, May 8, 2019 7:04 PM
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!
Monday, June 24, 2019 2:07 PM
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, July 8, 2019 10:52 AM
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.
Thursday, July 11, 2019 11:26 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.