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
way.
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.
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.
just had the same problem with 6 machines (xp/vista) in a network with folder redirection to a unc path. Acrobat9/AcroRead9
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
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?
Has Adobe coming up with a scheduled date for a fix?
One of our customers stopped the rollout of Reader 9 and therefor stopped the complete Adobe Forms Project.
The described "workaround" is not accepted by our customer.
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.
Hi all
After I finished the workarround with changing the APPDATA path to a hidden network drive, Adobe Acrobat 9 is now working.
BUT now when I would like to create an new link on the desktop, he don't refresh. I have to klick on F5 to refresh. Does anybody has the same or a simular problem?
I have created some Special GPO that links the Appdatafolder to %userprofile%\Appdata and applied the GPO only to the Users of Acroread/Acrobat. I'm very unhappy with this solution/wordaround, but it is working.
I am very dissapointed to discover that in Adobe CS4 the acrobat reader bug still exists.
The only solution is to either map the share to a drive letter and modify the registry so the profile is directed there (as above) but I have found that this causes serious problems with other programs and can cause profiles to not be loaded properly due to the drive not getting mapped in time.
I then created a more elaborate shortcut script which would modify the profile path and then open the program and modify it back but this also caused problems with other programs.
This problem has occured ever since Acrobat Reader Pro/Standard were released. It is surprising how difficult it is for Adobe to create an application for viewing pdfs which does not instantly crash when you open it.
Surely a major bug like this should not take many months to fix and when you have to remorgage your house to buy the CS4 Master Collection I feel you should at least be able to view pdfs without getting "This application has requested the Runtime to terminate in an unusual way. Please contact the application's support team for more information". So can you give me more information and/or possibly fix this sometime?
My only real solution which was also the same in CS3 is to avoid installing the Acrobat program and use Foxit Reader or to install Acrobat 8 which does not suffer from this problem/or 6 Pro to edit pdfs which I still have a licence for.
It naive to think that Acrobat and/or Reader would be changed with the
release of CS4 if it was not fixed before it was released. The version
in CS 4 includes the same version of Acrobat as was included in CS 3.3
and the technical suite interim update as well. When/If it is fixed it
will be distributed via the update mechanism for all running versions of
Acrobat and Reader 9.
To downgrade to acro reader 8 and install Foxit for those that get ver. 9 pdf documents is our best solution, and more and more people are liking foxit ... so we are contemplating to just start to use foxit for all our pdf needs since Adobe is not willing to fix this... Too bad really, they must be driving alot of customers away...
It's just when it costs so much money you would think a major bug like this would be A, discovered by beta testers before the 9 release or B, fixed by now as it has been many months and when every other application was updated in CS4 I would have at least expected a ver 9.000001 that would just fix this very annoying bug as apart from this the program is quite good.
As I understand it, Acrobat looks at the root of the UNC share and then tries to create a folder which alredy exisits consisting of the name of the user. There is no error handling in the code so the program just crashes. The error seems to be in one dll file.
I had to give people log on locally rights just to use this program and this makes the machines less secure as it is harder to apply security.
I called Adobe again today to enquire on the status of my support case for this. It was raised 3 months ago on Saturday.
After 20 minutes on hold, here's how the conversation went after I gave him the case number:
"Oh, this is an old case."
- "Yup"
"Uh, it seems to have been closed for some reason."
- "OK, that's interesting as I specifically agreed with the last guy it would not be closed until a fix was available."
"... the person who closed it does not work here any more."
GREAT.
I then spent the next 10 minutes explaining to this poor guy (who was clearly not near the support level dealing with this kind of problem) why the workarounds that had been previously suggested were completely unsuitable for enterprise implementation. He admitted all he could do is pass that feedback back up as he had no further information. He said he would get back to me ASAP.
]There is no solution yet.
]The issue will be fixed by the next Acrobat update. Please make sure your auto updater is active and/or check the Adobe website for updates.
That's all I was given. I have enquired as to if there is an expected timeframe for said update.
175
Replies
AdChoices