An out-of-memory error for Publisher 2010

Posted: November 29, 2013 in Applications
Tags: , , , , , , ,

This is a recent problem I ran across.  One of my users was trying to create a hyperlink in Microsoft Publisher 2010.   However, during that process, she received an Out of Memory error.

However, like many long term Citrix admins will realize, an Out of Memory error is much more frequently an issue of access to the file system.  This was my first suspicion to the problem.

My first step was to check the various registry paths in HKEY_CURRENT_USER for that user.  As I went through, I checked multiple locations that could have contained a clue to the problem.  I went through the various keys under HKEY_LOCAL_MACHINE\Software\Microsoft\Office\14.0\Publisher.  There were no values or keys that contained any paths that might have been an issue.  In fact, there were no file paths that I could find, other than the typical MRU (Most Recently Used) entries.  Those file paths were all files that she had access to.

I asked more questions about her activities, and what was happening.  She indicated that she was also having trouble saving some files, unless she went through a very specific set of gyrations to open the file, and even that sequence was not foolproof.

That’s when I pulled out one of my favorite tools, SysInternal’s Process Monitor.  (For people unfamiliar with this tool, it is a utility developed by Mark Russoinovich before he joined Microsoft, and it has been updated many times since he joined Microsoft. The tool monitors and captures all disk activity, network activity, registry activity, etc. taken by Windows.  Even a few seconds capture will show thousands of entries.)

I configured Process Monitor to only watch the activity from Publisher’s executable – mspub.exe.  In order to minimize the captured data, I turned on the capturing, tried to create a link, and turned off the capture.  I used the Search tool, and looked for ‘ACCESS DENIED’).  I found a few file system entries for this. The ones that caught my eye however, were these:


What really caught my attention was the operation and the associated directory – Create File and \\server\users.  This particular directory is the user’s home directory, and I know that several folders are redirected by policy to the user’s home directory.

Back to the user’s registry!  For those unfamiliar with the spot in the registry for Folder Redirection, it is located at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders.  The various values control the various special folders’ locations.  So, with this information, I changed the various paths in her registry from their redirected locations, to local paths on her system.  In order to make sure that Windows ‘saw’ the correct location was to force it to reload it.  Logging her off and back on would ruin my changes, and given the amount of work it would take to get her out of those policies, that did not make sense.  The quick and dirty method to do this is to force Windows Explorer (the actual shell) to restart.

Method 1:
Press Ctrl-Alt-Del and start Task Manager
Find the explorer.exe process, and select End Task.
Method 2:
Open an elevated cmd prompt
Enter in the command ‘tskill explorer’ or ‘taskkill /im explorer.exe’ (note that tskill requires that you not put the extension in the file name, while taskkill requires that you do put the extension name in).

Explorer will automatically restart, regenerate its environment, including the user’s folders. Knowing that I was close to an answer, and being impatient, I changed all the paths, restarted explorer (method 2 with tskill).  I relaunched Publisher 2010, and tried to create a hyperlink — Success!.  Now, it was just a matter of changing the paths back, and then changing them one at a time to locate which folder was causing the problem.

It turned out to be the Desktop folder.  It looked like Publisher was trying to create a file on the root of the redirected desktop folder.   I changed her desktop folder to her mapped home directory (e.g. u:\desktop) and Publisher continued to work properly.  On a hunch, I tried this same tactic without restarting explorer.  Again, success!  So, restarting explorer was *not* necessary, and Publisher had to have the “correct” value to work correctly.  Further testing, revealed that

  • She had to have permissions to create a folder at the root of the home directory path. Giving her that permission temporarily worked, but was not a good long term solution.
  • Changing the folder redirection to a mapped drive worked, but was really not a workable solution – I didn’t want to have to revisit this architecture.

The next challenge was to figure out how to correct this situation without changing her Desktop redirection.  (Re-architecting the entire structure (directories & policies) for an occasionally used application was out of the question). Like many other times, I figured a good script should handle the problem.

The script below does exactly this.  It reads in the current setting, changes the Desktop redirection to the mapped drive so that the user is unaffected and launches Publisher.  This worked also.  But, leaving the redirection changed is risky.  So, I set the path back to the original location that I had read in originally.  On first iteration, this script failed.  But, this had worked earlier by hand.. the conclusion was that the script was changing the value back to the original path was happening before Publisher had a chance to read it in.  I added the sleep delay at 5 seconds, and that failed.  I tried it at 30 and it succeeded. It was just a matter of tuning the time.   The final script also launches Publisher itself.

Here is the script:

Option Explicit
Dim wshShell
Set wshShell = CreateObject ("WScript.Shell")
Dim sDesktopPath, sHomeSharePath, sHomeDrive, sHomePath, sMsg, sTempDesktopPath, sPublisherPath, sRegDesktopPath, vbQuote
'Initialize vbQuote for adding " marks to strings
vbQuote = chr(34)
'Get the original desktop path
sRegDesktopPath = "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Desktop"
sDesktopPath = wshShell.RegRead(sRegDesktopPath)
'Get the home directory information from Environment variables
sHomeDrive = wshShell.ExpandEnvironmentStrings("%HOMEDRIVE%")
sHomePath = wshShell.ExpandEnvironmentStrings("%HOMEPATH%")
'Locate the install for Publisher
sPublisherPath = wshShell.RegRead("HKLM\Software\Wow6432Node\Microsoft\Office\14.0\Publisher\InstallRoot\Path")
sPublisherPath = sPublisherPath & "mspub.exe"
'Surround the publisher path with " marks to allow it to launch through vbscript
sPublisherPath = vbQuote & sPublisherPath & vbQuote
'Check if the Desktop directory is a UNC path
If Left(sDesktopPath, 2) = "\\" and lcase(right(sDesktopPath, 7)) = "desktop" Then 
 'It is a UNC path, so put in the new home value path
 sTempDesktopPath = sHomeDrive & sHomePath & "Desktop"
 wshShell.RegWrite sRegDesktopPath, sTempDesktopPath, "REG_EXPAND_SZ"
'Launch Publisher with the new value in place
 wshShell.Run sPublisherPath, 1, vbFalse 'Wait for 15 seconds
 WScript.Sleep 15000 'Put the Desktop path back into place to avoid other potential issues. 
 wshShell.RegWrite sRegDesktopPath, sDesktopPath
 'Doesn't look like a redirected path. Just launch publisher
 wshShell.Run sPublisherPath, 1, vbFalse
End If
Set wshShell = Nothing

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