Adobe Reader X/10 - continued crash problems trying to save PDFs

Question

Dear all,
I wonder if anyone can help me.... I have been having ongoing problems when trying to save PDF documents online while using the downloaded Adobe Reader 10 or X version. It always crashes/freezers when I press the 'save' button in the 'save as' dialogue box. I have to use end program and start all over again.
I use Windows XP (Professional, Service Pack 3) and both Mozilla Firefox 4.0.1 and IE 8 web browsers. I have followed the links suggested to prevent in future after the problem has been reported - I have unstalled and reinstalled Reader a few times now, as well as checked that I have been using the most up to date version of Reader 10 or X. Then reopened everything again thinking it's solved and then crash (ARGH!). Has anyone else had similar issues?
This is most frustrating to say the least, not withstanding the time delays affecting work outputs when the system crashes on the 'save as' dialogue box (after pressing save). I have lost faith in Adobe now ... I used to consider the free download of Reader a great asset, now it is a true annoyance and may or may not work entirely.
Any help or advice would be great, even alternative PDF software.
Many thanks in advance
Ruth

Answer 1

The response from 370H55V is correct in theory and in actual fact was very close to the solution, but the response was more cryptic than helpful. I first encountered this yesterday after upgrading users on a Terminal Server from Reader v8 to v9. My first instinct was to upgrade to v10, which I did, but the problem still existed, so I rolled back to v8 and the issue was resolved. Unfortunately however this was not a solution and it was a requirement that we upgraded to at least v9. The error was as described that in IE 8 when a PDF file was opened inside the browser(or embedded as some might say), and you press SAVE (or even sometimes print) within the adobe reader toolbar, IE would flicker and crash on the page and then recover the page, saying this page has been recovered, but no saving would happen. This would happen if protection was turned off in Adobe Reader, and if it was on (default), then pressing SAVE would just make IE freeze as previously reported.
So to understand what was happening, I ran FILEMON and REGMON by SYSINTERNALS. Regmon showed nothing of significance. Filemon showed a lot more. It was getting an access denied error on c:\windows\system32\shell32.dll. There was no reason for this however because the permissions on this file allow all users to read and execute. But then I remembered what shell32.dll does. It brings up the SAVE AS dialog box that allows you select the path of where to save the file – essentially this is calling the shell of explorer.exe.
So this is actually the cause of the crash. When Adobe Reader makes the call to the SAVE AS dialog box – CRASH!!!!! Why???
Well it’s quite simple. The default location that the SAVE AS dialog box starts in is MY Documents and this is where to start looking for the source of the error. To find out were “my documents” is for your session, open REGEDIT and go to:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
Look for the key: PERSONAL and in it is a REG_SZ containing the path to “my documents” for the current user. This is generally something like C:\documents and settings\<username>\My Documents on Windows XP/2003 and something like C:\Users\<username>\Documents on Win7/ 2008.
Now in our case the setting for this key was U:\ which was a mapped network drive to the path: \\server\username\mydocs. U:\ did exist and the user had full permission to it. So I changed the path on the personal key to C:\documents and settings\<username>\My Documents – the default setting. I went back to IE, opened a PDF document from a website, viewed the file and then pressed SAVE on the adobe toolbar. BINGO BABY!!!! Worked perfectly.
But again this was not a solution because in a network, you need your users to have their “my documents” in their own home drive, which is generally located on a remote share on a server. So I put the PERSONAL setting in the registry back to U:\ and crash back to square one. I then put the path of the U:\ in the key instead of just U: drive, so PERSONAL now had a REG_SZ value of \\server\username\mydocs. Went out to IE again, launched a PDF, pressed SAVE. BINGO BABY!! It worked. So clearly this was a UNC Path resolution issue or something similar, but why did it only happen from v9 of Adobe Reader and whose fault is it – Microsoft or Adobe. Well I suspect both. I suspect that Adobe maybe making a weak Shell call in their code which doesn’t resolve the path properly, and a possible bug in the MS Shell call may be adding to this issue.
Anyway, I did some further testing for some fun. I took permissions away from the user to their “My documents” folder and was also able to replicate the same crash. I set the PERSONAL registry key to a folder that didn’t exist and same crash. So basically if the SAVE AS shell call can’t resolve or access the path as set in the PERSONAL key the you will get this crash.
The way I solved it for the network users, was to set the registry key for PERSONAL to \\server\username\mydocs via Group Policy, also a logon script may also work. Additionally you could use Folder Redirection in Group Policy to set the path for MY Documents on a per user basis. This also was tested and work.
For non-network users check the PERSONAL key and get the path and then find that path and check permissions etc. Replace it with the default location or even point it to a path that you know exists and has full access.
As a final tip, also look at the registry Key:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
And find the PERSONAL path. It will be something like %USERPROFILE%\my documents in XP/2003 and %USERPROFILE%\Documents in Win7/2008. This is the default location and if the PERSONAL KEY does not exist in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders then windows reverts back to the User Shell Folders key to get the path. It is a good idea to check that path in this area as well.
Hope this helps.