Jump to content

1709 Windows Explorer Freezes when right clicking Internet URL Shortcuts


Recommended Posts

Posted

Hi,

 

I've only just noticed this on Monday this week and wondering if anyone has experienced this and/or fixed it?

 

- Fresh install of Windows 10 Education 1709 (using WDS) vanilla with no apps removed, but all security updates installed in the build.

- Log on to machine (whether it's a local or roaming profile)

- Use any internet browser and make a shortcut to any website on the desktop or anywhere else

- Right click on that shortcut and the blue circle starts and windows explorer freezes, then restarts. Also opening System or Apps and Features just has a blank screen and won't open properly.

 

This is on PC's that are about 18 months old and have Samsung Evo SSD drives. I've tried doing numerous builds and captures, but I get the same result.

 

I have tried just using a vanilla install from a USB key and then building up the drivers, updates etc. and that seems to go OK.

 

I have also replaced an SSD with a HDD and that works fine, so seems to be something with the SSD's in Windows 10.

 

This is Bizarre!

Posted (edited)
This is on PC's that are about 18 months old and have Samsung Evo SSD drives.

Which model are the Evo SSDs?

 

There's a known freezing issue with the 960 Evo/Pro SSDs...

 

https://forums.overclockers.co.uk/threads/psa-new-samsung-m-2-960-evo-pro-ssd-freezing-its-buggy-firmware-fix-within.18804729/

 

The 840 Evos also had a slowdown issue, but that model is probably too old to be in your PCs.

Edited by Arthur
Posted (edited)

Hi Arthur,

 

Thanks, Samsung Evo 840's.

 

I'll have a read of that link you sent. It's very strange because out of 4 identical machines - 2 have been fine. A third one was ok, then as a test I rebuilt it again with the exact same image and that now has the issue.

Edited by thatley
Posted

Unfortunately yes, that's one of the first things I tried.

 

I'm pretty much 95% sure it's the SSD causing this. I've just downloaded a vanilla build off of the VLSC 1709 .iso and deployed that with no changes whatsoever, no software, policies etc - same issue. I'm just deploying it now with the SSD in IDE mode as some people say that fixed the issue (with slower performance obviously).

 

This could be catastrophic as we have a number of schools with the Samsung 840 throughout!!! Won't be able to deploy Windows 10 on those sites.

 

Frantically trying to find a workaround/fix.

Posted
I'm pretty much 95% sure it's the SSD causing this. I've just downloaded a vanilla build off of the VLSC 1709 .iso and deployed that with no changes whatsoever, no software, policies etc - same issue. I'm just deploying it now with the SSD in IDE mode as some people say that fixed the issue (with slower performance obviously).

 

This could be catastrophic as we have a number of schools with the Samsung 840 throughout!!! Won't be able to deploy Windows 10 on those sites.

That's really strange. I have around 50 PCs running Windows 10 v1703 with Samsung 840 EVO SSDs and don't have any major slowness/freezing issues. :confused:

 

Does running winsat formal -restart clean from any elevated Command Prompt make any difference? This will force Windows to detect the SSD as an SSD.

 

The other thing you could do is secure erase the SSD (but keep the drive in AHCI mode) as this should restore performance. Parted Magic has an app for secure erasing drives.

Posted

Hi Arthur,

 

This is on version 1709 so not sure if that's the issue also. I haven't tried the winsat command so I'll give that a go. I did the whole secure erase, Trim optimisation etc, but that didn't help.

 

I will try a 1703 build to see if that works as a test.

Posted (edited)

Hi Arthur (or anyone!)

 

Not sure if you can throw any logic at this.

 

- Ok, I tried 1703 and that works every time I rebuild from WDS, so looks like an issue with 1709 and either Samsung SSD's or all SSD's (I'm trying a different brand this morning to confirm).

- Trying 1709 again, but taking out the unattend.xml on the build (which joins domain, adds in keycode, sets language and adds a local admin account) and ran through the OOBE on the machine manually - that works fine!!!

 

So it seems to happen only on SSD's, when you deploy via WDS with an unattend.xml file (which does nothing special and actually does everything it's meant to do!) It works when you deploy onto a HDD every time.

 

I don't get it! Makes no sense whatsoever.

 

Help!

 

------------------UPDATE-----------------------------------

 

Just tried 1709 with an OCZ SSD - same result!

 

Just tried on VM (Host has SSD) - same result!

Edited by thatley
Posted

For anyone interested - I've found out what is causing the problem (and only on deployment to SSD drives!)

 

In the AutoUnattend.xml, if I take out the GMT Standard Time entry from both the Specialize pass and OOBE pass - Windows 10 1709 works perfectly!

 

How F'ing weird is that!!

 

I now need to find a way of setting the Timezone automatically!

  • Thanks 1
Posted (edited)

Fixed! (after 4 days of solid testing - what a waste of my time!)

 

1. Removed GMT Standard Time entries in Unattend.xml

2. Added a script in '$OEM$\$$\scripts\setupcomplete.cmd' which gets installed at end of rebuild and runs 'TZUTIL.exe /s "GMT Standard Time"

 

Reporting this to Microsoft as I have no idea whatsoever why this would only affect PC's with SSD drives in.

 

Anyone?

 

 

--------UPDATE----------

 

False alarm - still f**ked! Logged it with Microsoft

Edited by thatley
Posted (edited)

Whilst I'm waiting for Microsoft to acknowledge this:

 

To sum up after carrying out countless tests on PC’s and VM’s, this is where I’m at now:

 

• Deploying windows 10 1709 from WDS either using an unattend.xml file or using the setting in WDS under the AD DS tab ‘The following location’, to PC’s with an SSD Drive – installs perfectly and all settings take. However, windows explorer.exe hangs when you

either open ‘Settings’ (or anything that resides in settings) or you right click on an Internet URL shortcut.

 

• This doesn’t happen if I don’t use an unattend.xml and leave WDS to put each domain joined PC into the ‘Computers’ AD container with no other settings.

 

• This doesn’t happen on the same PC’s if I put in a standard Hard Drive

 

• This doesn’t happen if I deploy Windows 10 1703.

 

• I have tried this on Samsung Evo 840's, 850's and OCZ SSD's.

 

I have two Server 2016 Domain Controllers (separate networks on separate VLANS) and I get exactly the same symptoms on both networks.

 

If anyone will be doing 1709 with this method over the next few months, I advise you to try this on a VM as soon as you can to see if this happens for you. If you do try, please report back here with your findings as this could help many others in the long run.

 

Cheers.

Edited by thatley
Posted (edited)

Just a quick update in case anyone experiences this issue:

 

This is in fact to do with having the GMT Standard Time entry in Unattend.xml I initially thought I'd fixed it by taking it out and adding it to the setupcomplete.cmd but this fails too as it applies before the reboot after windows installs. If I leave it out and manually set the time zone after the first reboot, everything works perfectly once logged on.

 

I have reported this to Microsoft and I have a couple of other organisations looking into it and will be trying to replicate the issue, so hoping someone will have a workaround/fix soon!

 

Does anyone have a good method / script that sets the time zone post install and syncs the right time for the computer and every user then on? Tried various GPO's with various reg changes but it's not reliable.

 

Thanks.

Edited by thatley
  • Thanks 1
Posted (edited)
Does anyone have a good method / script that sets the time zone post install and syncs the right time for the computer and every user then on?

Doesn't Windows automatically sync the time when you join a PC to the domain? :confused:

Edited by Arthur
Posted
I've just downloaded a vanilla build off of the VLSC 1709 .iso

Out of interest, are you using the English (en-US) or English International (en-GB) ISO from VLSC?

 

If the en-GB ISO I wonder if you could get away with not setting the timezone?

Posted
Doesn't Windows automatically sync the time when you join a PC to the domain? :confused:

 

Hi Arthur,

 

Unfortunately not and I think this is because the TimeZone by default is set to PACIFIC Time US/Canada. If I manually run w32tm /resyn after the timezone is set to GMT Standard Time it syncs with the server - doesn't seem to do it automatically.

 

The version off the VLSC I'm using is "SW_DVD5_Win_Pro_Ent_Edu_N_10_1709_64BIT_English_MLF_X21-50143" but if I leave all language settings out, it defaults to US system locale etc.

Posted
The version off the VLSC I'm using is "SW_DVD5_Win_Pro_Ent_Edu_N_10_1709_64BIT_English_MLF_X21-50143" but if I leave all language settings out, it defaults to US system locale etc.

I wonder it it's worth testing with the English International ISO (SW_DVD5_Win_Pro_Ent_Edu_N_10_1709_64BIT_Eng_Intl_MLF_X21-50145.iso) to rule out a bug with the en-US ISO?

Posted
I wonder it it's worth testing with the English International ISO (SW_DVD5_Win_Pro_Ent_Edu_N_10_1709_64BIT_Eng_Intl_MLF_X21-50145.iso) to rule out a bug with the en-US ISO?

 

Funnily enough, I've just finished downloading that Arthur - thanks.

 

Also, I've just rebuilt a machine but changed "GMT Standard Time" to "Pacific Standard Time" and that worked!!!

 

I'll try with the international version now and see what happens.

Posted

OMFG!!!! IT WORKED!!!!!

 

Why the hell would that work? Only affects PC's with SSD's? Defies all logic.

 

I'll update MS on this, but from now on, i'm going to use the English_International version.

 

Bizarre!!!!!!!!! I'll continue testing as sometimes it does actually work by fluke.

 

Thanks for the pointers BTW Arthur :)

  • Thanks 1
Posted
Bizarre!!!!!!!!!

It's definitely the strangest Windows bugs I've ever heard of! :)

 

It will be interesting to find out what the cause is if Microsoft ever get to the bottom of it.

Posted (edited)
It's definitely the strangest Windows bugs I've ever heard of! :)

 

It will be interesting to find out what the cause is if Microsoft ever get to the bottom of it.

 

Me too. I've been plugging away at this since 10th January - what a waste of time.

 

I'll report back if I ever get a response from Microsoft.

Edited by thatley

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...