C.T.L.S. (Check the Logs Stupid!)

Ever hear of K.I.S.S.? It’s an old acronym that means “Keep It Simple Stupid!” because it’s usually something simple causing your problem, something stupid simple like the device isn’t plugged in. Well today, I’m going to tell you about my new favorite, C.T.L.S. “Check the Logs Stupid!”

I currently manage a fleet of laptops for analysts who do a great deal of travel, so obviously they need to be connected on the road. While I have an MSI file for the Verizon Access Manager software, it hasn’t been installing during my MDT deployments for the last few weeks. It was installing fine for months, but for some reason unbeknownst to me at the time, I was getting the notorious 1618 error message which really just means “something bad happened, sorry”. I checked the BDD.log file and didn’t get much help.

Error 1618 – Not very helpful.

Well, thankfully since this package was an MSI, I was able to check the msi log file in my share (see my logging article here).

An even more confusing error.

When I checked the log for the installer I got an error 258: Failed to grab execution mutex. While at first glance this seems to be just as cryptic as the previous error, a little bit of googling led me to some forums and threads that suggested this can be caused by certain software (like antivirus) needing to reboot after instalation.

To fix this, I went in and set the antivirus to reboot after installation, a sure enough my problem went away. The problem wasn’t the wireless software, it was the application getting installed before it requiring a reboot.

Set to enable reboot on install in MDT 2012.

By setting the application installed before the problematic software to reboot after install, my problem went away, but I would have had a hard time knowing that if I hadn’t checked the logs. So the moral of the story is, enable logging and then check the BDD.log file and if that doesn’t help, hunt down the log file of the application msi install itself.