Update: Looks like Anton talked about this in a recent blog post. I feel like I’ve won an insignificant victory by being a good 6 months ahead of him on this. Original article Published on: Dec 26, 2013 @ 15:26.
For those of you not aware, SCSM 2012 SP1 CU4 (or UR 4, depending on who you ask) was released in the middle of November. I’ve been heads down on a current project, so I just recently discovered it. In patching a development environment, I ran into the following error:
The referenced exception is System.IO.Exception. This is a generic category for any IO operation throwing an exception. This particular error cropped up immediately after accepting the EULA, and was consistently occurring on the test systems.
I have run into this in the past when patching a management server, and it seems to have been introduced sometime around SP1. typically, if i run into this area, I apply the patch MSP files directly. however, since this was a development system, I spent a little time digging into the issue using the SysInternals suite, specifically Process Monitor and Process Explorer.
I was able to trace this down to a sharing violation on the QFEList.xml file that lists the Windows Installer patches to apply as part of the update. Essentially, the PatchWizard executable opens this file and reads it before displaying the EULA, but for whatever reason doesn’t release this handle when it’s done. Once you click the Install button, PatchWizard tries to open and read that file again, only the original file handle is still open, so this creates a sharing violation.
The fix I used involved manually closing that file handle using Process Explorer before accepting the EULA. You’ll want to start the patch, wait for the EULA acceptance screen to pop up, open process explorer, find the PatchWizard process, look at it’s open handles list (usually in the bottom pane), find the QFEList.XML handle, right click and close handle. Accepting the EULA will then process without error, and the patch will install correctly.
I make no guarantees on the supportability of this fix. you are officially on your own if you try this, but there doesn’t seem to be much mention of this on official channels, probably due to Service Managers sparse usage. There are some posts on the Microsoft forum that recommend installing a list of .net updates, but they’re pretty vague on specifics, and none of the referenced updates claim to provide any file handling fixes. Here is one that does, but it’s more then 2 years old, and subsequent updates were already applied to my dev environment. This whole problem seems to be in the undocumented unsupported grey area, so +1 NaCl.