Reader 9.0 AcroRd32.exe caused Microsoft Visual C++ Runtime Library error

Steve,

The easier way to do that, is to just disable folder re-direction from group policy. Your way will just get overwritten based on group policy anyway.

BTW, in the reg path, you missed current version.

Here's how we solved this annoying problem:

0. You probably should start off by being logged in with your Domain Admin account.

1. Create a folder off the root of your C: drive. My username is skobb, so I created C:\skobb

2. Click on Run and type REGEDIT

3. Follow this path:
HKCURRENTUSER > Software > Microsoft > Windows > Explorer > Shell Folders

4. Create a backup of your registry by exporting and saving the file to some other part of your file structure. You can always go back to this by double-clicking on the file name

5. In the right-hand pane of the registry editor, find all paths with UNC references and change them to the local folder that you created in Step 1.

So, for example, I changed...
\\houfile1\skobb$
to
C:\skobb

6. Make the same sort of changes in another folder on this same path called "User Shell Folders".

That's all there is to it. Fire up Acrobat 9 and it will behave itself.

It did for me, anyway.

Good luck to all frustrated citizens of AcroWorld, wherever you may be.

Steve

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.

Hello!

Does anybody know if there is some fix available somewhere at
adobe.com or at least a date they do think they will release
one?
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
did ...

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.

Bernd Leutenecker

Classy... I'm with you there James.

I'm not rolling out Acrobat9 to those on folder redirection. While it is nice to have a work around, the better solution is to have a fix.

James,

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**

Be safe and Be well!
Penrath

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?

Nice post designingpatrick! Thanks for letting us know a workaround. We just rolled everyone back to 8.1.2 and it works fine with roaming profiles in vista as they are setup.

When Reader 9.1 comes around we will drop it in the test lab and see what is next.

Be safe and Be well,
Penrath

'Acrobat 9 doesn't like UNC-Paths(path beginning with \\) as AppData path.

Just change the following AppData registry entries to non-UNC paths and acrobat starts up correctly

[HKCR\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]

[HKCR\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders]

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. '

http://www.adobeforums.com/webx/.59b5d982
"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 ===

Solution?
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. "

Hi
Any updates on this yet?