For most of the time I've had my ThinkPad T60 laptop (running Windows XP SP2) and Advanced Mini-Dock, when I would undock the laptop from the docking station, the ThinkVantage Access Connections application would automatically and successfully enable the machine's wireless radio and connect me to the local wireless network.
However, following a recent (May 2008) round of system software updates installed via ThinkVantage System Update, this no longer worked. After undocking, the wireless connection would not automatically be made, and when I tried to manually connect using ThinkVantage Access Connections, the attempt would fail on the first step of the process, "Applying wireless settings."
After encountering this failure, I would be able to get the wireless to work correctly once again by rebooting the machine. (Needless to say, I wasn't happy with this workaround, due to the delay involved in rebooting, and the need to close all open applications.)
The Fix - Executive Summary
The Fix - Long Version / Investigation
On one recent occasion where I undocked and subsequently encountered the issue, the ThinkVantage Access Connections service process, AcSvc.exe, crashed (with the typical Windows XP "This application has encountered a problem and needs to close" crash dialog). I restarted the process (via the ThinkVantage Access Connections application shortcut on the Start menu), and after doing that, the wireless started working again, with no reboot involved. This led me to believe that the issue was with the Access Connections software.
I reproduced the undock issue again, and this time manually killed the AcSvc.exe process (via Windows Task Manager), and restarted it, and that once again got the wireless networking to work. So at that point I at least had a better workaround than needing to reboot.
I continued to investigate the issue, and found a post on the Lenovo Support Forums indicating that another ThinkPad owner was having an apparently unrelated problem with AcSvc.exe, but that he was running Access Connections version 4.52, and that he had been able to resolve the issue by reverting to version 4.42. I checked my ThinkVantage System Update log, and noticed that an upgrade to Access Connections 4.52 had been among the changes in the recent round of updates I had installed. A co-worker who also had a T60 and was having no wireless issues also reported that he was running Access Connections 4.42. Armed with all of this information, I decided to try reverting to Access Connections 4.42 to see if that would resolve the issue.
I was somewhat nervous about doing this, since if the Access Connections installer didn't do a good job of handling the case of installing an older version of the software on top of a newer one, I could conceivably left in a broken state where my network connectivity (both wired and wireless) might not work at all. To try and mitigate this risk, I backed up the registry entries and program files for Access Connection 4.52 before proceeding.
Fortunately, the Access Connections 4.42 installer had good handling for installing over a newer version: it recognized that I had a newer Access Connections version installed, and (with my approval) uninstalled the existing version before installing the 4.42 version.
Following a reboot, with Access Connections 4.42 installed, the laptop now once again automatically and successfully connections to the wireless network following an undock!
There was one remaining minor issue, though. With Access Connections 4.42 reinstalled, I started seeing a new issue where upon an undock, I would get an error dialog with caption "netsh.exe - Unable to Locate Component", and dialog text "This application has failed to start because framedyn.dll was not found. Re-installing the application may fix this problem."
Fortunately (and unlike for the original "Applying wireless settings" failure issue), help was readily available via a Google search for this issue. Per a suggestion given in several of the search results, I copied the file framedyn.dll from my C:\Windows\system32\wbem folder to the C:\Windows\system32 folder; with this done, the error dialog now no longer appears.