Last night, I decided to rearrange my studio a bit to use the shape of the room more to my advantage (which is rectangular) and forgot to hook the interface back into my computer before I powered it back up.
Of course, it shouldn’t have been a problem given that the drivers were supposedly installed, but due to an unforeseen problem involving an obscure file called “INFCACHE.1” that I hadn’t even heard of before, I was simply stumped at the inability of Windows to recognize the device yet again after all these months, and to make things worse, I had a client I was supposed to do a session with over Skype that I had to postpone because I couldn’t get the session to run without the interface. Not good!
Step 1: Get a Second Opinion
So I called a friend of mine (who happens to be a network systems administrator for Cisco) and asked him what his thoughts were regarding the issue.
He told me it had something to do with a file in the Win32 folder and how Windows was perceiving the device as well as the respective installation software for the device in the first place. So, I did a Google search and came across an interesting blog page that had a solution that I was bound to try out (albeit cautiously).
From what my friend had explained to me, I learned that the INFCACHE.1 file contains instructions telling Windows how to install USB devices and keeps a backlog of said devices so that they’ll be easily recognizable in case said USB devices are plugged or unplugged, and in the event that it’s corrupted, any such devices that are unplugged will not be recognized nor will the software of such devices install (easily, that is).
Step 2: Process of Elimination
So, after removing the INFCACHE.1 from the folder, I proceeded to install the software by running the setup.exe as usual, and ended up with mixed results.
The session would open up and seemed to be initially operable, but for some reason the samples (i.e. the audio files that are actively being used in the session) wouldn’t load properly, and consequently, I assumed was the DAW trying to load samples onto the buffer but couldn’t do so because the audio driver was still corrupted or incorrectly installed. So I force-quit the session, used a freeware cleaning utility called CCleaner to clean out any empty or unnecessary entries in the registry, reinstalled the driver, and booted up my DAW once more.
This time more samples were successfully loaded, but the process only reached 94% and just “stopped”.
Step 3: Stay Calm and Think
At this point, I wasn’t too happy and my client was due to call me back any minute to ask me if I was ready to get to work. As stubborn as Windows was being at this point, I decided that trying to install the device via the Installation Wizard was as good of a move as any at this point, and luckily, it worked!
So what’s the moral of the story?
Well, if there’s anything that I think anyone can learn from this, it’s that troubleshooting can come in all shapes and sizes, and you constantly have to be prepared for it.
This means that you constantly back up your files, keep offline copies of all your essential software accessible so you can reinstall them if need be, and just be prepared for the unexpected to happen.
Additionally, it doesn’t hurt to have extensive knowledge about how computers work or know someone who does (like a programmer, a network systems admin, or anyone who works with computers day in and day in for a living). I hope you guys find my story useful should you find yourself in a similar situation!
