Service Manager 2012 SP1 CU4 and System.IO.Exception

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.



  1. As far as I know (at least for previous patches) the file will be released if you mark some of the EULA text. Perhaps the intention was to assure people to read the text before proceeding or scroll down to the end, only the code is not quite finished :)

    1. I haven’t seen that behavior before, but I’ll certainly try it out the next time I have a chance to apply patches. Even if that were the case, thou, it would still seem to be a File Handle handling bug, since any given scope of code should either close the handle because that scope is done with that file forever, or leave the handle open for the same scope to access it again in the future. It’s possible that this stems from trying to pass a handle between scopes (functions, objects, etc) which seems, to me at least, like a bad plan from the start.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s