Buggy Windows 8 network charms - works from command-line!

I have struggled with two network related problems on my older laptop for some time after upgrading it to Windows 8 and later 8.1. Both problems occur when I try to go to the Settings charm (Winkey+I), in the submenu under the networking icon (upper left of the icons). Both however seem to have one very simple workaround: Using the command-line equivalents.

Problem 1 - Connect to WLAN: Sometimes, registering to a known WLAN does not work, or the connection is randomly or immediately lost after being registered. Sometimes, the desired WLAN network is not even visible in the networks list, although any other WLAN capable device (e.g. a phone etc.) can find the WLAN in question.

Solution 1 - Connect to WLAN from the command line: For some reason, connection works great when doing it from the command line. To see all avaiable WLANS:

netsh wlan show networks

Issue the following command to connect to one of them:

netsh wlan connect name=WlanName

-where WlanName is the name of the WLAN. Observe that this name is case sensitive!

Those are the basics - explore other possibilities by using the help system (a ? sign  will give you available commands).

Possible mitigating factor to this problem: I am using an Intel 4965AGN network card, which some suggest is not supported under Windows 8. However, the Windows Compatibility Center suggests otherwise - at least for Windows 8 (while 8.1 is marked with "no info"). I have had bluescreen problems with both the Windows 8 native driver and the latest Intel driver, but the latest Dell driver works for me (version 12.4.3.9 dated May 28, 2009) on my Latitude D830 without bluescreen problems.

Problem 2 - Connect to RAS (PPTP) connection: When trying to connect to one of my RAS connections (VPN to another location), sometimes I loose the WLAN connectivity even by clicking the desired RAS connection on the Settings-networking charm, without even clicking its Connect button that will now be displayed. Needless to say, when my WLAN is gone, so are my chances to connect to the RAS connection. I am stuck.

Solution 2 - Connect to RAS from the command line: Again, performing the same task from the command line succeeds without any hassle. Here's the command:

rasdial "RAS connection name" username password

More information about problem 2: What happens when clicking the RAS link, seems to be that the WLAN Extensibility Module crashes and logs an event 10003 and an event 10000, "WLAN Extensibility Module has failed to start" with a reference to the file IWMSSvc.dll and an error code 1726

Source files missing from project, but still there (Linking error)

Situation: Some .cpp and .h files shared between several Visual Studio Project files in different VS solutions (I know - bad practice, but it was not my idea and I could not change it) were being relocated to a separate directory beside the solution dir of the project I was working on. By unloading the project in VS, then manually editing the .vcxproj file, it was a simple task to search and replace string entries like:

     ClCompile Include="folder\
with
     ClCompile Include="($SolutionDir)..\folder 

Since the job involved much more reorganizing, and there was a lot of other files in the project as well, it was not unexpected that several referencing and linker errors occurred along the way. 

Symptom: In the end I was faced with a linker problem I was not able to get rid of. LNK2001 and LNK2019 errors were filling my screen. I diffed the old and the new .vcxproj files to search for what I had lost along the way, but found no apparent problem at first. Not until I closely examined what reference the linker could not find, making sure that both a header entry and an implementation body (usually in a corresponding .cpp file) were actually present in the project. Somehow some of the files were not!

Problem: It turns out that for file references, the .vcxproj file simply ignores files written with MsBuild variable references like my ($SolutionDir)..\folder\file.cpp -They show up when you view the .vcxproj file in a text editor, but not from within Solution Explorer. Update: Seems like the MsBuild variable actually sometimes works (see the strikeout above), but not in the combination with double dots for jumping one step up in the folder hierarchy. Needs verification what conditions are for this problem to occur.

Solution: Once I had replaced the ($SolutionDir)..\folder entries in the .vcxproj file with the more boring and less flexible ..\..\folder, everything was fine.

SyncBack hang/freeze on Windows 7 - SMB version problem

Problem: SyncBack Free is a brilliant free tool for synchronizing two folders' contents fast and accurate. I had been using a Windows XP computer with two network cards standing as a bridge between two networks to sync folders between two computers residing on each side of the bridge. Old of age the XP computer were looking forward to its retirement as a young Win7 computer were set up to take over its place. The same SyncBack running the same SyncBack profile on the Win7 computer completely hung the SyncBack process within seconds after syncing was attempted. Only a reboot would kill the process - not even Task Manager managed to take it down.

Factors in the picture:

• The two remote computers were running Win7  and Server 2008 R2.
• Syncing between a local folder on the Win7 computer and one of the remote computers would work. Just not syncing between the two remote computers.
• It made no difference whether Windows Shell (on the Copy/Delete tab) was used to sync or not.
• Copying files between the remote computers from Windows explorer works just fine.

Problem reason: The reason proved to be SMB version. WinXP uses SMB 1.0, whileas Win7 uses SMB 2.0. For some reason, SyncBack does not manage to copy files between two remote computers as long as the computer is set up to use SMB 2.0.

Solution: Disable SMB v. 2.0, forcing the Win7 computer to revert to using SMB 1.0. This excellent article on Petri explains how - or here in short: From an administrative command line window run the following commands and then reboot to activate (Observe that "bowser" is actually correctly spelled - or rather, it is spelled the way that the computer understands):

sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled

If you need to revert to SMB 2.0, use the following commands:

sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc config mrxsmb20 start= auto 

I have not put any effort into researching whether security is an issue with these settings or whether other functionality is negatively affected, for me it gave me what I needed, so I am happy.

Windows Photo Gallery would not open a file on the desktop

Situation: I often use the desktop for temporary storage of images or documents I am going to throw away after a very short while. When I tried to open a JPG image on the desktop by doulbe-clicking it, there was no reaction however. Standard program for viewing images is the Vista native "Windows Photo Gallery."

Problem analysis:

• Doubleclicking the image or rightclicking, selecting preview or open with - Windows Photo Gallery all produces the same result: Nothing
• Doing the same on another file residing in any other folder works perfectly.
• Moving the image file in question to any other folder makes it open like a dream. Moving it back restores the problem.
  
• Rightclicking and selecting open with - also works.
• Rightclicking and selecting open with - choose default program makes the file open in the other program you choose upon doubleclick or richtclick - preview.
  

Problem identification: Windows Photo Gallery has a problem opening image files residing on the desktop.

Clue: On a web forum I found a clue that it might be due to another file on the desktop being corrupt. He suggested moving all files except the image file(s) on the desktop to a folder on the desktop. Having done that, IT WORKED AGAIN! I had moved away a couple of PDFs and two internet shortcuts, that did the trick. By moving one and one file back, I was able to identify one of the internet shortcuts as being my problem:

Solution: An internet shortcut containing a very long URL (a direct pointer to an online shipment tracker) was a showstopper. Removing this shortcut from the desktop did the trick.

I figure it must be some kind of a buffer overflow issue or something.

Web browsing stops working; ping, skype, nslookup etc. still fine

I believe I have got another Vista hate item on my list: Every now and then, particularly after some time of heavy browsing, the web browser suddenly stops working. Ping, nslookup and Skype still works, but neither Firefox, Internet Explorer, Thunderbird or FTP (from CMD) work any longer.

Investigation: A net trace using Ethereal Wireshark reveals that using IE or Firefox, no packets are ever leaving the browsers when I try to make a request for a web page. Obviously, there's something wrong in the internal OS parts that prevent packets from ever being created. OS parts because the problem applies to both IE, Firefox, Thunderbird and FTP (and more?) - OS is what they all have in common.

Possible solution: There's a lot of rubbish advice out there on different forums and blogs that advice to reset routers, disabling firewalls etc., which does not address the problem at hand. My best clue yet is Microsoft KB937168, which describes a problem pertaining to those with ICS (internet connection sharing) enabled. I happen to have just that.

Microsoft has a rigorous process for downloading the needed update, however The Hotfix Share seems to provide what is needed (if you can afford the risk of downloading from another site than Microsoft itself).

I will update this post when I have some certainty as to whether the problem is really solved - i.e. after hours of successful browsing without any hickups.

UPDATE 14.1.08: Problem is still gone - I am terminating this as an "under research" topic, assuming that the solution is found.