One of the biggest, bestest, and most-hyped features of Windows Vista (according to Microsoft, that is) was the brand spanking new TCP/IP networking stack. Ask us, it sucks. Network performance hasn’t improved any over the ancient stack used in XP (nor should it – it’s not like there’s anything new in IPv4) though it does add better IPv6 support out-of-the-box and ships with some even more functionality in Windows 7. But more importantly, Microsoft threw out decades of testing and quality assurance work on the existing Networking Stack and replaced it with something rather questionable.
We’ll be following up some more on this topic from a technical side later in another article, but for now, an example that most of you are sure to have come across if you’ve ever tried to map network drives before:
This popup is shown at system startup if you have any mapped network drives to UNC shares which are not protected with a username and password. If you map a network destination that does require authentication, Windows will map the drive OK. To further complicate matters: this message is shown only when you startup from a cold boot! If you restart your PC (vs shutdown and powerup), it won’t appear.
Resolving the issue is straight-forward enough: just double-click on the network drive in My Computer and it’ll automatically, instantly, and silently connect. Which makes one wonder why Windows couldn’t connect in the first place.
While working an update to Genie Timeline, I ran across this issue. Windows wouldn’t connect a mapped network destination at startup for some of our customers, meaning that our backup couldn’t continue (assuming you’re backing up to the network drive) until you manually intervened and opened the mapped drive yourself. Definitely not cool.
As an in-house R&D test, we attempted to manually re-establish the connection via the command-line. By running
net use Z: \\remote\path\
we were able to re-establish the “disconnected” network drive. But when we tried to implement this in code, we came across a funny issue. If you try to run this very early on during the logon procedure, it will fail with error code ERROR_FILE_NOT_FOUND – basically, it’s unable to contact the network path. The funny thing is, explicitly testing to see if we can connect to the network path [GetFileAttributes(networkPath)] doesn’t return any error. But Windows itself is unable to establish a connection. Using ‘net’ from the commandline was just a workaround for R&D purposes, so we turned to the trusty old WNetAddConnection2 function – and it too failed with ERROR_FILE_NOT_FOUND even though the network path both definitely existed and was perfectly accessible as a UNC location!
Attempting either of these techniques to establish a mapped network drive connection later on – say 2 or 3 minutes after logon – works just fine. As does attempting to establish a connection to a UNC path that requires authentication. Or attempting to connect to the network drive after a restart and not a cold boot.
In the end, we resorted to calling WNetAddConnection2 at timed intervals after startup if the UNC path is accessible and the mapped network drive is not. It got the job done, but it really does speak volumes when developers have to run through hoops to address issues that have been out 2 OS releases and 5 years ago. We have no such problems with Windows XP.