A client has updated Adobe Reader 8.1 to 9.0 on several machines and now cannot use Adobe Reader.
The program start, the Adobe Reader window appears but no document and then an error message is displayed that says;
"Microsoft Visual C++ Runtime Library
Program: C:\Program Files\Adobe\Reader 9.0\Reader\AcroRd32.exe
This application has requested the runtime to terminate in an unusual
Please contact the applications support team for mor information."
Adobe Reader has been removed, the computer restarted and then re-installed from a full installation package and the problem persists.
This is the same or similar to the message I got. I have roaming Vista profiles and folder redirection on a Server 2003 domain. Administrator (non-roaming) has no problem. Roaming non-admins get message like (or same) as you get. How does your set-up compare with mine? I reverted to Adobe 8 -
Another irritation - I installed Adobe 8 from a thumb drive & whenever I update it wants the same thumb-drive letter in place. I have learned NOT to install from thumb drives. I am even leary of installing from a network location - in case I re-organize folders
Same problem here, seems to be directly related to folder redirection....
Tried filing this as a bug, but they don't allow more than 2000 characters.... my trace files are way bigger than that.... I'm going to file a bug and link them to this thread as I'm going to put some of my trace info in here.
This has been tested on multiple machines, with multiple users. It does not occur for users without folder re-direction.
In our tests, XP doesn't have the problem with Roaming Profiles, but Vista and folder redirections does.
Steps to re-produce (Vista):
Set the following policy settings (GPMC/Local Sec Policy) with adjustments for server, etc.
User Configuration (Enabled)hide
Setting: Advanced (Specify locations for various user groups)hide
Grant user exclusive rights to AppData(Roaming) Disabled
Move the contents of AppData(Roaming) to the new location Disabled
Also apply redirection policy to Windows 2000, Windows 2000 server, Windows XP, and Windows Server 2003 operating systems Disabled
Policy Removal Behavior Leave contents
2) Install Acrobat Reader 9.
3) Launch without admin priviliges
When debugging with ProcessMon (Sysinternals) on Vista SP1 x64 I see it calls \device\mup and then a createfile at the root of C:\ which fails with access denied (as it should in vista), and then the program calls the Windows Error Reporting.
This is lines 9378 to lines 9406 in the processmon trace, sanitized.
I'm seeing the same problem with the full version of Adobe Acrobat 9.0 Professional, in what seems to be the same setup. We've just bought a site licence for Acrobat so at least I should be able to kick up a fuss with support, unlike anyone using Reader...
The exact error messages I'm getting are:
>Microsoft Visual C++ Debug Library
>Program: C:\Program Files\Adobe\Acrobat 9.0\Acrobat\Acrobat.exe
>The application has requested the Runtime to terminate it in an unusual way.
>Please contact the application's support team for more information.
and when viewing PDF files in Internet Explorer:
>Microsoft Visual C++ Debug Library
>Program: C:\Program Files\Internet Explorer\iexplore.exe
>abnormal program termination
>(Press Retry to debug the application)
My Domain Admin account is not affected, even when I assigned it a roaming profile temporarily. I tried adding an affected user to the local Administrators group and this had no effect - the user still experienced crashes. I'm pretty sure it's to do with the AppData redirection, which my Domain Admin doesn't use but the affected user does.
The same user logging onto one of our laptops (which are set to always use local profiles and AppData even for domain users) does NOT experience crashes.
I've managed to generate a crash dump for this and from reading through the stack trace it appears the problem stems from the PDFLTerm() function in AdobePDFL.dll
>WARNING: Stack unwind information not available. Following frames may be wrong.
I too have run a ProcMon trace, this time on Vista Enterprise x64, and got similar output to CH! above, though in my case Acrobat issued a CreateFile on the root of the DFS share hosting the redirected AppData, with CreationDisposition set to CREATE_ALWAYS; in other words, trying to overwrite the share... Unsurprisingly this resulted in a NAME COLLISION since it already exists, and a call to WER immediately followed: and can't be overwritten.
to setup the profile path in the usersettings pane in the Active Directory user and computer mmc to connect the profile path with a drive letter instead of the UNC-Profile path.
So instead of \\server\profile\%USERNAME% we use U:\profile\%USERNAME%.
You can also setup the users to local profiles, than the path would be a default path like c:\Documents and Settings\%USERNAME%\AppData. '
"Acrobat 9 (reader and pro) do not play well with Redirected Folders in an Active Directory environment. More specifically... a redirected "Application Data" folder.
Any of my users which do NOT have roaming profiles (aka redirected folders) have no problems running acrobat 9. In other words, users who have their "Application Data" folder in "C:\Documents and Settings\username\Application Data" are fully functional and do not receive the C++ Runtime error. "
"==== THIS IS WITH ROAMING PROFILE CRASHES! ====
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)
net use l: \\SERVER\USER PROFILE TREE\USER PROFILE
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. "
Adobe emailed me yesterday suggesting I change the registry keys, still not realising that the settings were Group Policy controlled, and therefore if I wanted to change the AppData folder I would have done so already.
I'd considered mapping a drive letter as designingpatrick suggested, but I don't consider changing Group Policy for 1500 users just to accommodate Adobe's buggy code a particularly appealing solution, so have decided to hold off the roll-out until Adobe fix it. I told Adobe the same and asked for an ETA on a proper fix, and can you believe that this is what I got in response?
>We are not able to give you any date about this issue but the engineers are working on it and this issue will probablty (sic) be solved with updates of Acrobat 9.
>I will close your Case
Close my case?! You can imagine the prompt and firm reply that elicited. I run a helpdesk. We don't close cases until they are actually fixed. This has never seemed like a bad approach to me. Your thoughts?
I am in the same boat you are. My network users have a very strict permissions on the accounts...and I have a LOT of them. They can't even do their own updates for adobe..it's all handled through GP. I am not going to muck around with registry settings and so on for over 2000 user accounts in several OUs
The simple answer is to continue to use 8.1.2 or use something provided by open office or Foxit (just to name a few).
It really all boils down to what the users are doing with Adobe reader and what you can...and can not... put up with.
It comes as no surprise that an odd numbered release would be buggy anyway... right? **grin**
Does anybody know if there is some fix available somewhere at
adobe.com or at least a date they do think they will release
Knowing that Adobe Software in Version x.0 tends to be buggy,
we waited until today to roll out Adobe Reader 9.0. We've even
checked right before if there is a newer (german) version
available on ftp.adobe.com.
Installing it as an administrator (without roaming profiles
etc.) we did not stumble upon this error. But now our users
By the way: We have had rather similar problems (but as far
as I remember not with that particular error message) with
other Adobe products (v 8 / CS3) with folder-redirections
and roaming profiles.
This is what I heard from Adobe Support yesterday:
>I will keep the case open and give you further notice when there is a solution provided.
So, there is no fix at present, only the workaround provided above. For what it's worth, we use v.8.1.2 with Roaming Profiles and redirected Application Data without any problems, so sorry to hear you've had trouble with that too.
The UNC path problem with programs is nothing new.... Flash, now Adobe flash, has exactly the same issue as the new version of Reader. Which would leave me to believe that Adobe might not care about it or isn't planning to fix either product. I had been told that flash would be fixed almost a year ago by a software company (Scholastic) that uses flash to create the learning software for kids that we use. I've yet to see any new versions that allow for Active Directory "App Data" folder redirection.
That's curious. We have Adobe Flash Player 188.8.131.52 deployed to almost every computer in our organisation, and none of our users have experienced any problems (including those that have AppData redirection). What symptoms are you seeing?
It is flash runtime... It's not that flash doesn't work, but if the software developer needs to have flash store setting for users, such as a server to connect to, the settings need to be saved in the users app data folder. But if you've redirected the app data the setting won't save as it is a UNC path and the user will have to re-imput the settings. I just tested this about a month ago and it was still not working. To get around this I have the users login as a generic AD user that has a non-redirected app data folder. Or I'll setup the specific shortcut to the application to do a "run as" and have the user us an account with out a redirected app data folder.
FYI if you change your shell folder registry settings, you'll break vista. There's some documentation on this if you read MSDN about vista's folder virtualization.
Also, if you use the login script solution to map the drive, you'll lose your other apps user data, because they all understand UNC paths and will be looking in the original locations. So in my opinion, that's not a proper work around.
My company is simply going to NOT upgrade to 9. Perhaps when Adobe realizes the ramifications of thousands of unsold copies of Acrobat 9 this will outweigh the development costs associated with updating their code to support UNC.
This in a script and the script in user/autostart. It works perfect and thanks to the author. ... ;-)
Experiences with Adobe Support.
"Yes, we know about it, but we don't support that. We support windows but we never promised acrobat to work under these circumstances. And we don't know if we're going to support it!"
As if folder-redirection was a third party add on!
In my opinion this "bug" ist just poor programming skills especially if the reason is local-path / unc-path.
Just remembering. On the change from Win95 to WinNT4.0 there was a problem that adobe just ignored the "new" permissionsystem in the registry and the user required full access to the registry for photoshop and/or pagemaker to run! ....
Had a similar problem with saving photoshop pictures to redirected my documents - UNC path doesn't work - but mapped drive - to the same location does. Group policy uses UNC path, so you can manually, or script, the my docs location to use the mapped drive path and you are right. Of course GPolicy is supposed to do away with fiddly scripting since about 10 years ago - nice one Adobe.
I think all Adobe support have a big sign in front of them with "That is not supported" in their cubicles. Standard response for several problems I've called about. Although they did offer to give me a support ticket number. What for? To call me every 2 weeks and remind me I have an issue outstanding that they will not support? For the prices they charge, the support is appalling. I would blow them off in a moment if our users didn't consider them the "defacto" industry software. Hopefully someone with a decent will start eating away their market, and they will be forced to actually support users.
I just had a user who was having trouble with Adobe 9, and it ended up being the folder redirect. I do consulting with a small firm and we have seen more and more trouble with the folder redirection of Application Data recently. We have a lot of clients who use CAD programs and AppData redirect is a mess with those programs.
When weighing the pros and cons, the only thing we feel we are losing by not doing folder redirect of AppData is the .NK2 file for Outlook which is the users auto-complete cache when they are typing a name into a new email. We can easily copy this single file over with an xcopy that grabs any file with a .nk2 extension in the users directory. We are in the process of redirecting all AppData back locally and just redirecting MyDocs and Desktop.
Why Doesn't adobe do anything about this?
I can't believe that Support is so... not supportive on this incident.
We spent about 45 minutes trying to figure out if there was a way to customize this in adobe customization wizard.
I would think that there should be a way to customize it in the registry..
like change the path of the application data folder?
or maybe statically map it always or somthing.
Has any one had any better response from support on this issue?
This fix does not work when you redirect the Application Data directory with Group Policy. The folder redirection happens as part of the logon processor before the script processes... You simply do not use a drive letter with this option in group policy - and you can't change it (to the same location) later as it resets back to the GP applied UNC path immediately.
In other words - Adobe needs to fix this, these work around solutions are not acceptable, nor functional in many situations.
My fix is to go back to Acrobat Pro 8.0, and copy the Objects, Templates and Samples directories from '%ProgramFiles%\Adobe\Acrobat 8.0\Designer 8.0\EN' to '%APPDATA%\Adobe\Designer\8.0\EN' for the user with %APPDATA% redirected to a UNC path... Which gets the LiveCycle Designer 8.0 to run with out the same basic error.
Edit: I've cross-posted this in a few of the threads so far... There should be a way for the 15 or so active threads on this to be brought together...
I am wondering if there is a way to get adobe to use the application data in the all users profile stored on the local machine instead of the app data in the redirected folder. I have in the mean time decided to not redirect the app data folder. I am still able to redirect all other folders. This will require a little more time for users to log in, however it should not be too bad (I hope). If adobe would just use the AppData folder in the all users profile, then they would not need to worry about UNC paths, all though I don't know why a company today would not support UNC's.
If anyone has any ideas about how to make this work or if it would work, please let me know.