It appears something was changed by update (rollup) KB4015549 that caused the "could not reconnect all network shares" issue to happen, or worsen. Has anyone else noticed this? Or thinks I'm barking up the wrong postman? Long story short: I installed a new PC (HP 800G2 Mini) with Windows 7x64 Ultimate two months ago. At the time, I used the Simplix* pack from February to update the clean SP1 install. At first I got the "could not reconnect all network drives' issue but by the time I had finished my setup and changed the network startup policy, the issue was resolved. The PC hasn't had that issue since then, until... I updated from April's Simplix pack (17.4.20) a few days ago, and on reboot the "could not reconnect..." issue started. It happened every startup since then - about ten times without fail. Only three updates were listed in in 'programs and features/updates' from that update. The other two looked innocuous so I uninstalled KB4015549. Since then, I've started up about five times without the "could not reconnect..." issue. So, it looks like something in KB4015549 is the culprit. I have a couple of startup programs that get upset if Windows tells them there is no mapped network drive, so I'm sensitive to this issue. At the moment I'm torn between wondering if I really need the update for some security hole, and having my PC work the way it should. I hate Microsoft! * I don't mean in any way to imply this problem is caused by the Simplix pack itself - it's a wonderful tool!
No, intel i7-6700. Thanks for the thought though. It seems removing the update hasn't worked. The day after I posted my OP the 'could not connect' issue came back and happens every startup now. Something changed with that update though, because I did not have the issue before it. I currently have a script reconnecting the share at startup, followed by starting the programs that rely on it. Not perfect, but better than it not working at all.
Have you checked the logs for any related eventID errors or warnings ? If so, could be helpful to post them here. Also you could check services.msc to see if all network related services are running. If you don't know which ones that should be, just type msconfig in the run box and on the general tab select 'Normal Startup'. It will load all default services upon next boot. Could be your network shares are lost because some service state got altered by some other update. I'm suspecting this because normally if you have rolled back the faulty kb4015549 patch, the issue should be gone. Another possibility is some registry key or value got screwed up, which could be traced back if we have some related eventID...
Sorry it took a few days to reply. I stopped my script and put the system back how it was to get the log entries, but the issue did not happen again until today. I really hate intermittent problems. I find it odd though that it doesn't always happen, and didn't for quite some time until this update. I expected it to. On the other PCs I have seen this issue on, it happens every startup. There are no warnings or errors in the logs and all the services are running as they should. I did notice the following timing in the system log: 12:38:14 First log entry for this boot 12:38:19 Intel driver reported connection at 1Gbps 12:38:26 Various networking services starting (DHCP, DNS, etc) 12:38:29 Network List service started 12:38:36 Network Connections service started I have no idea at what point in all of that that Explorer fails to see the network share. The PC boots quite quickly from SSD and I got this exact same problem on three other (very different) PCs when I upgraded to SSD from a spinning HD. It's the same issue that is all over the internet, with various supposed solutions that sometimes make a difference, but don't for me. I've tried them all. Microsoft as usual seems to pretend the issue doesn't exist. The problem isn't just that I get the 'can't reconnect' message, it's the fact that once Windows/Explorer has failed to see the share, other applications cannot use the share until I open Explorer and double-click the shared drive letter. It then instantly 'connects' and everything is fine, except several programs have already failed by that point and that causes them problems. So, even delaying startup of those applications does not help because Windows still tells them there is no network share until I manually kick it. The answer seems to be just to use my script to reconnect the shares every boot, instead of having them remembered.
Do you use the Win7 Homegroup or standard workgroup ? I always had issues working with homegroup myself, until I gave up and put all hosts inside a workgroup. If you have non-Win7 hosts, homegroup usually doesn't work as supposed, which was my specific issue then. I suppose your FW is set up correctly ? Have you tried with it turned completely off ? If you set up Host A with an account and password, try to set up Host B with the same account and password, and see if Host B can see a networkdrive sourced from Host A... But again, if you are using one or more non-win7 hosts in a homegroup, the homegroup could be the issue.
No, I've never used Homegroups. The mapped drive I'm most concerned with is to a WD NAS, but I get exactly the same with mapped drives to other Windows 7 PCs and my Server 2008R2 box in the loft. (I'm not on a domain though; don't be distracted by the 'server' ) I've also tried (some time ago on another PC) having no personal firewall on - no difference. I use Windows 10 Firewall Control anyway, which uses WFP so that shouldn't be an issue at all unless I've mucked it up (which I haven't). I have all static IP addresses, all PCs are in the same workgroup (if that even matters any more), wired network, the switch (a L3 Gig Cisco) set with Portfast on the access ports so no STP slowing down the link, all on the same VLAN (no router to go through to the shares), I don't use any AV program that might get in the way (shock, horror, lol), 'wait for network' is enabled in group policy, exactly the same username/password on all PCs (I do that anyway, they're all mine), etc etc. I've never found a proper solution to this issue, and in the past I have tried very hard to discover one.
Yeah, I had the impression you were on a home network. By the looks you got things under control pretty good though. Your share permissions are setup correctly yes ? In any case, the behavior is recognizable (to me), but the connection with KB4015549 is not. Let me just say that years ago there was a bug in Win7 in which, whenever you use a drive letter to map a share it failed to autoconnect, until you browsed it in explorer. F.e. \\<servername>\<share>\... worked but \\<drivename>\share\... didn't. It was confirmed by M$ as a bug, but little afterwards. I haven't used network shares in windows at home for years so don't really know whether it got resolved. Haven't heard much about it since. Seeing that it DID work for you before the update indicates it did get resolved along the way though. There are workarounds though, like in your case using a script, or f.e. with Network Magic you can map the drives using a descriptive name instead of the drive letter, but since it only works on Cisco networks (I think) it is irrelevant here. You can still try some things, like using the ip adres of the host/nas instead of the host name or vice verse, make sure you didn't double map them (through profile+in GP), do a system restore to 'before' those three updates, remove all 3 updates to be sure, etc... Just curious, what were the other two KB's ?
Nice try - you've read the same posts I have Neither of those work for me. The NIC setting made no difference at all, even though it seemed that it might be the answer. Actually, I recall it did make some difference that I noticed somewhere but it certainly didn't improve the issue. I cannot use Sync because I have Windows remember the credentials for the NAS box (so I don't have to type them in every logon), so Sync is simply not available for it (isn't Windows wonderful ).
Lol, I would have thought that I point the fault to google though, since it began truncating the search results Windows is a friggin pain in the ... Mainly Linux 4me @home. Windows I use mostly for music alone these days (no Linux version 4my daw, and no Mac here). Been having audit failures myself, codeintegrity errors, injected by the audiodg service. Eventually I too gave up on finding a solution, and have set the error code to ignore. As my windows system is mainly 4my daw, disabling the service is a no go. No actual issues though, but I like to have my logs 100% clean. With windows that is not an easy task. Let alone the application logs... I guess if you have searched long and wide, you should probably do the same, or do a fresh install without those updates, IF you are sure it worked before. It is weird the updates would cause this, yet weird is the M$ normal I guess. Yeah I'm REALLY fond of those guys too REALLY happy to have had them in my life
In 2016, a year ago or 0.9 years ago, I had that kind of issue. I was having that kind of issue right off the bat, with a clean install! SFC also reported corrupted files on a clean install! Was this a Redstone 1 bug? Or all RTMs, since 10240?
I just noticed the first of those two posts - only saw the second before... Share permissions are definitely correct and I've tried mapping the drive letter both by NetBIOS name and IP address. No difference. It seems related to that bug, and it hasn't been resolved. Like you say, browsing the mapped drive in explorer triggers it to work. I'm sure it's simply(!) a case of Windows not being able to handle many things starting up more quickly than the networking services, due to being on a nice, fast SSD. It's intermittent though; occasionally it will work now, but mostly not. Just to keep me on my toes Even my script doesn't manage to get the mapped drive up until about five seconds after I get the desktop, but at least it works. The other two updates are: KB4015193 and KB4014565. I've just thought of one other thing I can try: it never occurred to me before to point to the file on the NAS (in the 'open file' dialogue of the application that needs it at startup) by manually entering the IP address of the NAS. I had tried the mapped drive letter and NetBIOS name both of which fail when the issue happens. I'll report back tomorrow...
Hmm... partial success. One application works fine, although like my script it obviously doesn't get the network for several seconds after the desktop is up. Another application though fails more often than not, even hangs, but works occasionally/eventually. I guess that one really doesn't like not having the network there immediately and panics.
I'm pretty sure it was post SP1. Yours would have been the same if injected by the audio service, like l3codeca.acm or audiodg.exe... There was also a memory leak coming from audiodg.exe which got fixed through a hotfix later on, yet this audit failure, though connected to the same events, was never resolved it seems. You could implement a pause in your script to bypass those first seconds, though it wouldn't stop that application from freaking out, so still not a 100% fix... Glad it is partially working now though (let's see for how long, probably till the next dodgy update ) This shows that, even those that DO investigate thoroughly before updating, lots of KB's keep causing issues... For that 'promise' of security support till 2020, they sure manage to screw us over still in all kinds of dubious ways. I think we all have had our share of that 'security support' lately.
Just an epilogue to all of this... Uninstalling KB4015549 seems to have completely killed Windows Update. Not that I use it often, but today I wanted to see what else was available. First, trying to check for updates gave the error 'cannot run because the service is not started', or words to that effect. I went through the obvious troubleshooting for that, eventually running a Microsoft repair tool which told me the 'service registration is missing or corrupt'. The fix according to MS was to restore or reinstall Windows. Instead, I re-ran the Simplix pack and it reinstalled that one KB. Problem solved - update works again!