Tuesday, August 05, 2008

Watch out with ADOBE ACROBAT READER 9 on a domain with Vista user roaming profiles

Update: In researching this issue I came across an AWESOME step by step for installing Adobe written by Aaron Parker, that includes an MST of the recommended settings. All I can say is Aaron, you da man!http://blog.stealthpuppy.com/deployment/deploying-adobe-reader-9-for-windows
There also is a greate admin template to set up Adobe Acrobat to work so it opens OUTSIDE the browser. I had to do two things to get Adobe Acrobat to work on Vista. Logged on as an admin, go to the Adobe reader executable on the hard disk in the program files/adobe/9.0/reader folder and right click on it and choose properties. Then choose the compatibility tab and choose set compatibility for all users and choose Windows XP SP2 from the drop down. Apply. I then had to open Adobe reader, choose edit/preferences. Click on Internet in the side menu and uncheck the open in browser box. Hope this helps.
NOTE: If you have a solution to this please post in the comment section! Thank you.
I'm putting this out there everywhere I have a presence in hopes that Adobe will get off it's butt and fix this problem. If you install Adobe 9 acrobat reader on Windows Vista on a domain and use roaming profiles for users, be it mandatory or not, Acrobat Reader will crash and will not run. It gives errors in modules annots.api and also msvcr80.dll. Note that this is NOT an IE only thing, Acrobat reader crashes when run by itself, with Firefox and Apple Safari browsers as soon as the account is set to roam.

As soon as you give the user admin priveleges the program will run. I've tried turning off UAC, still broke, I've tried running adobe reader in compatibility mode, still broke, I've tried running adobe as administrator settings still broke. I've tried changing access on adobe folders to give users full control, still broke. Giving a user administrator priveleges is NOT an acceptable solution. Further having to mess around with Dep and Windows Security features is NOT an option. If Adobe wants to play with the big boys and try to consider it's product an "industry standard" they have to write it correctly.

I am not the only one having this issue there are posts all over the internet including the below samples IN the adobe forums.
Citrix admins have also reported issues with it crashing and getting it to work~
However I did find an installation script for Adobe 9 on Citrix
here Though I have not tested this so I do not know if it works.
My recommondation is don't install Adobe Acrobat 9 in a Vista domain until Adobe addresses this issue!
NOTE: Local non admin user profiles CAN run Adobe. If you make it a roaming one that is when you have issues.


Anonymous said...


Adobe's program iterates the network path from left to right, skipping the first word: \\Server\Folder1\Folder2\Folder3\APPLICATION DATA as it searches a user's profile for the APPLICATION DATA folder.

So starting at FOLDER1 it checks to see if it can "create" a folder. It doesnt do it, but it tries to check its access. If your not in the users profile at this point, the program MOST LIKELY cannot because its a directory NOT owned by the user. THe previous folders is something you wouldn't give NORMAL users access to.

After the program FAILS to "create" its folder because it cannot -
The program Crashes:
*R6025 - Pure Virtual function call
* The exception unknown software exception (0x40000015) occurred in the application at location 0x2e80f5e3
* C++ runtime error
* WINDOWS NAME Collision error.
=== ITS ALL OF THESE! Same error, different points in the crashing ===

I create a network drive DIRECTLY to the profile, then I update the registery to make that the WINDOWS APPDATA path. ALL of this is done on the user logon scripts. So it was just "solved" one day, except for a new drive letter appearing.

(Added to login script)
REG ADD "HKEY_CURRENT_USER\software\Microsoft\windows\CurrentVersion\Explorer\User Shell Folders" /v AppData /t REG_EXPAND_SZ /d "l:\Application Data" /f

For our work we use: \\SERVER\USER PROFILE TREE\%USERNAME%\%COMPUTERNAME% - so each user has SEPERATE data per computer they are on.

Anonymous said...

I use a VBS script and GPO settings to manage my domain. Here's a VBS script portion that will map an H-drive to your users folder, and fix AppData to it.

Set objNetwork = CreateObject("WScript.Network")
Set oshell = WScript.CreateObject("WScript.Shell")
' Set access to profile directory
objNetwork.MapNetworkDrive "H:", "\\servername\users"
wscript.sleep 1000
oshell.RegWrite "HKCU\software\Microsoft\windows\CurrentVersion\Explorer\User Shell Folders\AppData","H:\%username%\Application Data","REG_EXPAND_SZ"

*Registry editing guide I found to help with the VBS...


Anonymous said...

Thanks for the props Jim.


Anonymous said...

Hi thanks a lot for yours help !

I have the same issue, but I do not use roaming profiles, I'm in a Domain and for the Domain users the acrobat reader 9 crash in the annots.api module.

My not good solution : remove the annots.api file from his folder.

And your solution saves me lot of time :
As ab admin Go to the adobe reader executable on the hard disk in the profram files/adobe/9.0/reader folder and right click on it and choose properties and then t0 the compatibability tab and choose set compatibility for all users and choose Windows XP SP2 from the drop down. Apply. I then had to open Adober reader, choose edit/preferences. Click on Internet in the side menu and uncheck the open in browser box

Thanks again.

And nothing about this issue on adobe support site... shame


Anonymous said...

MY solution: Don't use reader 9 - keep reader 8 untill adobe fixes the program. Like Daniel Gorman brings on Reader crashes when it tries to do a CreateFolder or CreateFile and gets Access Denied. Apparently the programmer did something wrong when doing the exception handling since the exception is not caught by app and then Reader terminates with an error for this unhandled exception. Bad programming must say because as in this case programmer needs to catch every variant of the kind exception for a file operation like create - but he uses for a different purpose to test access. Bad bad.

Anonymous said...

On windows 2008 terminal server i only changed, on the executable Acrord32.exe the compatibility mode for all users to Winxp+SP2
Tested and it works...

Greetz... LeForge

Unknown said...

Thank-you for this tip! I'm been dealing with this little inconvenience for the past couple of weeks, after Adobe was nice enough to offer v9 (of course, I thought, why not!). I guess the saying, "Don't fix what isn't broke" truly does apply here. Oh and you may want to update your title. I've personally verified it also occurs in WinXP (I was running the x86 w/SP3--not that it really matters) and Windows Server 2k3 (x86)& 2k8 (x64). On the XP machine, I did try using the runas to run it under a local admin, and it did work fine. I do agree this isn't a good idea, especially w/Vista since it pretty much negates the security provided by UAC. I also tried using a local user (ie: std limited user) acct. and that also worked just fine.

Here's what I recommend, especially if you're lazy, like me;) Go ahead and create a new LOCAL user account, name it "adobe_reader". Set the membership to the "Support_388..." group. I believe this group is denied local logon privileges, so it's probably a better choice than "Guest". NOTE: It might be necessary to use the "user" group first and logon as the new acct to set up the directory structure. I just changed group membership on an existing local acct that I no longer use.

Next, create a shortcut or batch file with the following cmd:
runas /savecred /user:local_machine_name\adobe_reader "C:\Program Files\Adobe\Reader 9.0\Reader\AcroRd32.exe"

The /savecred will keep it from prompting for a password each time Adobe Reader starts (not sure if it saves thru a logoff/logon cycle). Also, you could use a blank password for the acct. I don't think this would cause much of a security risk, since the acct is pretty much useless for anything else (it can't logon locally, it can't logon over a network--a blank password should ensure this). All it can really do is access files set w/"Everyone" and probably "Authenticated Users" access. If you're still paranoid set share and file permissions to deny this acct. Make sure to not deny the necessary folders!

Hopefully, this helps until Adobe gets their act together, and fixes the roaming profile problem!