Skip to content

iTunes Upgrade Freeze Resolved – and an Enterprise KM Observation

As many of you know, one downside of a career in IT is that we get pressed into [unpaid] service as tech support for the family’s troubles with technology. My college-bound daughter has purchased her MacBook, and will soon find out (to her dismay) I have little hands-on experience with that platform. However, for many years both of my daughters have tethered their iPod to the family Windows desktop – I’ve done or thing or two over there. Fortunately (unfortunately?), I only get the call when the problems are significant, and the last big problems were no exception (two weekends down the drain …).

They had successfully filled the hard disk to 98% capacity, and performance had slowed to a crawl. I had to chip away at the cruft left behind by months of downloads, ripping, and ‘net surfing (BTW – can anybody explain why iTunes insists on making so many hidden copies of these songs?). The Internet is a wonderful thing – I got my crash course in the state-of-the-art for rescue disks and other file recovery utilities and processes – interesting stuff, but that turned out to be the easy part. The time-consuming problems came when I had to reinstall, and then upgrade, iTunes. After applying the latest version (7.6), I started it up – and nothing. No familiar library lists, no album covers – no music.

Being the techie type, I opened up Task Manager and saw all the right services running, but nothing appeared on the screen, So, a-Googling I went, and (consistent with previous experience), I saw I was not alone. I found threaded conversations, troubleshooters in forums, even a number of decent write-ups on Apple’s site. Again, I learned an awful lot about stuff I didn’t know before – the vagaries of registering DLLs (sccbase.dll slbrccsp.dll sccsccp.dll slbcsp.dll slbiop.dll and, of course, wmasf.dll & wmidx.dll), artifacts like iTunesAddIn.CalendarHelper, and useful utilities like Dependency Walker.

Still, after hours of struggle – nothing; color me frustrated, especially because the helpful folks on the other end of my browser didn’t seem to have a consistent solution either. Then at dinner, my oldest daughter mentioned that she’s seen this non-starter problem before. “I just plug in my iPod and the problem goes away”. No – it couldn’t be that easy …

… but it was. Restart the PC with a freshly installed upgrade – nothing on the screen, but I can see iTuneshelper.exe and iPodService.exe running. So I plug in the iPod and voilà, the crisis is over. Too simple, and I’m not sure if this is the solution that will fix things for everyone, but I want to capture this knowledge here as a favor to the next beleaguered dad who follows in my footsteps (hence all the tech stuff in the paragraphs above – Google search bait).

An Observation: Knowledge Management (KM) in the Enterprise

The ultimate solution was straightforward and simple, and I’m surprised that Apple’s upgrade instructions do not indicate any need to plug in the iPod to get things going. I don’t know if the plugging-in step is required – plenty of hits from my Google searches, but I didn’t get the sense that 80% of iPod users were having this problem.

I also noted that in all of these results / conversations, it’s rare to see a final, definitive solution captured. The write-ups are helpful for narrowing in, but I suspect after hours of struggling with iPod and PC, folks are just relieved to be done with it, and don’t think to come back to close the knowledge-capture loop by documenting the ultimate solution.

This phenomenon happens in the enterprise as well, especially when working on stressful internal projects or hot bug fixes for extended periods of time. You’re so sick of the problem that you don’t want to re-hash the process by capturing the detailed step-by-step in a nice, clear document. When you’re working on a product your company offers for sale, it makes sense to capture this knowledge – you can expect many users will call in with similar experiences. On the other hand, seeing well-constructed root-cause documentation for internal development or processes is rare.

Mitigation: For the tech going through the problem-solving process, a very effective approach is to keep a log of the things that you’re trying, and each dark alley you go down. This will make it easier at the end to go back, clean it up a bit, and put it in the knowledge base as a final document. The other way to drive this knowledge-capture behavior is to simply to require proof of full documentation before something is pushed into production. This is overhead and “bureaucracy” that most techies dislike, but it should drive better quality over the long term.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Articles
Capturing Knowledge

Capturing Knowledge: A Critical Requirement for Corporate Innovation

Drilling into the important role of capturing knowledge in promoting corporate innovation, highlighting the importance of creation & curation, sharing & collaboration, and impactful use.

Read more