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

Thanks for calling James, I'm still waiting on my VL media of pro 9 to arrive from the states to test, so that I'd have a "supported" edition, that they support to call in.

I went back through my trace, and I do see the same thing as you do creating the file at the root of the share, I didn't put too much pass on it originally because it was a success.

Well, I just got off the phone with Adobe UK Support with whom I have logged a case for this issue.

b The agent told me that this is a known issue that he was notified of yesterday (17 July). He confirmed it is an issue with the AdobePDFL.dll and is specific to environments using Active Directory.

b There is not yet an ETA for a fix.

He was not able to confirm that it is definitely linked to AppData redirection but it seems pretty clear that is what's causing it from the reports here.

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
>
>Runtime Error!
>
>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
>
>Debug Error!
>
>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

>ntdll!KiFastSystemCallRet
>ntdll!ZwWaitForMultipleObjects+0xc
>kernel32!WaitForMultipleObjectsEx+0x11d
>kernel32!WaitForMultipleObjects+0x18
>kernel32!WerpReportFaultInternal+0x16d
>kernel32!WerpReportFault+0x70
>kernel32!UnhandledExceptionFilter+0x1b5
>msvcr80!abort+0xeb
>msvcr80!terminate+0x4d
>WARNING: Stack unwind information not available. Following frames may be wrong.
>Acrobat+0x422e
>ntdll!__RtlUserThreadStart+0x6f
>ntdll!_EH4_CallFilterFunc+0x12
>ntdll!_except_handler4+0x8e
>ntdll!ExecuteHandler2+0x26
>ntdll!ExecuteHandler+0x24
>ntdll!KiUserExceptionDispatcher+0xf
>kernel32!RaiseException+0x58
>msvcr80!_CxxThrowException+0x46
>Acrobat_69630000!DllCanUnloadNow+0x68e27
>Acrobat_69630000!PDFLTerm+0x645ce
>Acrobat_69630000!DllCanUnloadNow+0x663df
>msvcr80!_NLG_Return

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.

>98959 11:29:15.6155113 Acrobat.exe 972 CreateFile \Device\Mup\ NAME INVALID Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
>99021 11:29:15.6181294 Acrobat.exe 972 CreateFile \\mydomain\users\ SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
>99100 11:29:15.6219431 Acrobat.exe 972 QueryStandardInformationFile \\mydomain\users\ SUCCESS AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: False, Directory: True
>99111 11:29:15.6222464 Acrobat.exe 972 CloseFile \\mydomain\users\ SUCCESS
>99182 11:29:15.6254897 Acrobat.exe 972 CreateFile \\mydomain\users\ NAME COLLISION Desired Access: Read Data/List Directory, Synchronize, Disposition: Create, Options: Directory, Synchronous IO Non-Alert, Open Reparse Point, Attributes: N, ShareMode: Read, Write, AllocationSize: 0
>99187 11:29:15.6257927 Acrobat.exe 972 RegOpenKey HKU\S-1-5-21-1708537768-2052111302-682003330-4640\Software\Adobe\Adobe Acrobat\9.0 SUCCESS Desired Access: Read
>99189 11:29:15.6258324 Acrobat.exe 972 RegQueryValue HKU\S-1-5-21-1708537768-2052111302-682003330-4640\Software\Adobe\Adobe Acrobat\9.0\Crashlog NAME NOT FOUND Length: 144
>99191 11:29:15.6258536 Acrobat.exe 972 RegCloseKey HKU\S-1-5-21-1708537768-2052111302-682003330-4640\Software\Adobe\Adobe Acrobat\9.0 SUCCESS
>99192 11:29:15.6259012 Acrobat.exe 972 QueryNameInformationFile C:\Program Files (x86)\Adobe\Acrobat 9.0\Acrobat\Acrobat.exe SUCCESS Name: \Program Files (x86)\Adobe\Acrobat 9.0\Acrobat\Acrobat.exe
>99193 11:29:15.6260191 Acrobat.exe 972 RegOpenKey HKLM\Software\Wow6432Node\Microsoft\Windows\Windows Error Reporting\Escalation NAME NOT FOUND Desired Access: Read

Hey All,

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
Policieshide
Windows Settingshide
Folder Redirectionhide
AppData(Roaming)hide
Setting: Advanced (Specify locations for various user groups)hide
Group Path
my_group_here \\server\users\dept\%USERNAME%\AppData\Roaming

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

342417 01:10.7 AcroRd32.exe 460 CloseFile \\server\users\dept\username\AppData\Roaming\Adobe\Acrobat\9.0 SUCCESS
342419 01:10.7 AcroRd32.exe 460 SetEAFile C:\Windows\CSC\v2.0.6\namespace\server\users\dept\username\AppData\Roaming\Adobe\Acrobat\9.0 SUCCESS
342420 01:10.7 AcroRd32.exe 460 ReadFile C:\Windows\CSC\v2.0.6\pq SUCCESS Offset: 269,632, Length: 208
342421 01:10.7 AcroRd32.exe 460 WriteFile C:\Windows\CSC\v2.0.6\pq SUCCESS Offset: 269,632, Length: 208
342422 01:10.7 AcroRd32.exe 460 CloseFile C:\Windows\CSC\v2.0.6\namespace\server\users\dept\username\AppData\Roaming\Adobe\Acrobat\9.0 SUCCESS
342424 01:10.7 AcroRd32.exe 460 CloseFile C:\Windows\CSC\v2.0.6\namespace\server\users\dept\username\AppData\Roaming\Adobe\Acrobat\9.0 SUCCESS
342426 01:10.7 AcroRd32.exe 460 CreateFile C:\ SUCCESS Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
342427 01:10.7 AcroRd32.exe 460 CloseFile C:\ SUCCESS
342429 01:10.7 AcroRd32.exe 460 CreateFile \Device\Mup\ NAME INVALID Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
342430 01:10.7 AcroRd32.exe 460 CreateFile C:\ SUCCESS Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
342431 01:10.7 AcroRd32.exe 460 CloseFile C:\ SUCCESS
342433 01:10.7 AcroRd32.exe 460 CreateFile C:\ ACCESS DENIED Access: Read Data/List Directory, Synchronize, Disposition: Create, Options: Directory, Synchronous IO Non-Alert, Open Reparse Point, Attributes: N, ShareMode: Read, Write, AllocationSize: 0
342434 01:10.7 AcroRd32.exe 460 RegOpenKey HKU\S-1-5-21-1669273076-1836279104-1734353810-3328\Software\Adobe\Adobe Acrobat\9.0 SUCCESS Desired Access: Read
342435 01:10.7 AcroRd32.exe 460 RegQueryValue HKU\S-1-5-21-1669273076-1836279104-1734353810-3328\Software\Adobe\Adobe Acrobat\9.0\Crashlog NAME NOT FOUND Length: 144
342436 01:10.7 AcroRd32.exe 460 RegCloseKey HKU\S-1-5-21-1669273076-1836279104-1734353810-3328\Software\Adobe\Adobe Acrobat\9.0 SUCCESS
342437 01:10.7 AcroRd32.exe 460 QueryNameInformationFile C:\Program Files (x86)\Adobe\Reader 9.0\Reader\AcroRd32.exe SUCCESS Name: \Program Files (x86)\Adobe\Reader 9.0\Reader\AcroRd32.exe
342438 01:10.7 AcroRd32.exe 460 RegOpenKey HKLM\Software\Wow6432Node\Microsoft\Windows\Windows Error Reporting\Escalation NAME NOT FOUND Desired Access: Read
342448 01:10.7 AcroRd32.exe 460 QueryOpen C:\Program Files (x86)\Adobe\Reader 9.0\Reader\imageres.dll FAST IO DISALLOWED
342449 01:10.7 AcroRd32.exe 460 CreateFile C:\Program Files (x86)\Adobe\Reader 9.0\Reader\imageres.dll NAME NOT FOUND Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
342454 01:10.7 AcroRd32.exe 460 QueryOpen C:\Windows\SysWOW64\imageres.dll FAST IO DISALLOWED
342455 01:10.7 AcroRd32.exe 460 CreateFile C:\Windows\SysWOW64\imageres.dll SUCCESS Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
342457 01:10.7 AcroRd32.exe 460 QueryBasicInformationFile C:\Windows\SysWOW64\imageres.dll SUCCESS CreationTime: 11/2/2006 6:16:57 AM, LastAccessTime: 11/2/2006 7:03:20 AM, LastWriteTime: 11/2/2006 3:39:37 AM, ChangeTime: 11/17/2006 11:11:23 AM, FileAttributes: A
342459 01:10.7 AcroRd32.exe 460 CloseFile C:\Windows\SysWOW64\imageres.dll SUCCESS
342464 01:10.7 AcroRd32.exe 460 CreateFile C:\Windows\SysWOW64\imageres.dll SUCCESS Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a
342466 01:10.7 AcroRd32.exe 460 QueryStandardInformationFile C:\Windows\SysWOW64\imageres.dll SUCCESS AllocationSize: 15,822,848, EndOfFile: 15,821,312, NumberOfLinks: 2, DeletePending: False, Directory: False
342470 01:10.7 AcroRd32.exe 460 CloseFile C:\Windows\SysWOW64\imageres.dll SUCCESS
342472 01:10.7 AcroRd32.exe 460 CreateFile C:\Windows\SysWOW64\en-US\imageres.dll.mui SUCCESS Access: Generic Read, Disposition: Open, Options: , Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a
342474 01:10.7 AcroRd32.exe 460 QueryStandardInformationFile C:\Windows\SysWOW64\en-US\imageres.dll.mui SUCCESS AllocationSize: 12,288, EndOfFile: 12,288, NumberOfLinks: 2, DeletePending: False, Directory: False
345240 01:12.0 AcroRd32.exe 460 Thread Exit SUCCESS User Time: 0.0156001, Kernel Time: 0.0156001

I wish I had read this earlier, just rolled the update on 30computers yesterday and now when people tried to open pdfs the fun begun. Quite nice undocumented feature :/ -> rolling back to 8.1

I think it has something to do with Adobe 9 not liking the path for "Application Data" being on the server instead of a local path.

I see you have roaming profiles too.
I have to check, but I think my user with folder redirection but not roaming was OK

My workstations are XP but they are roaming with folder redirection on a Server 2003 domain. Local accounts work fine but the accounts with folder redirection get that error.

I still haven't found a solution. I reverted back to Adobe 8 until a fix is found.

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

I have the same problem.

I am in an Active Directory environment with folder redirection. Is there a work around or fix?