Skip to content
← Share your feedback on Acrobat DC

Settings and activity

2 results found

  1. acrocef_1 folder is already generated at the time of new installation

    3 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    2 comments  ·  Acrobat for Windows and Mac » Installation and Licensing  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    An error occurred while saving the comment
    Anonymous commented  · 

    Problem still exists in version 2023.006.20360.
    This version introduces a new "feature", so that AcroCEF.exe is crashing multiple times when it was started with low integrity level. Crash happens because it can't load "libcef.dll" from same directory as the EXE path.

    Anonymous supported this idea  · 

  2. AcroPDFImpl64.dll crashes when PDF is accessed via ActiveX/Webbrowser Control x64

    3 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    5 comments  ·  Acrobat Reader for Windows and Mac » Other  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    Anonymous supported this idea  · 
    An error occurred while saving the comment
    Anonymous commented  · 

    @Bernhard
    Adobe didn't change the manifest of this file since I first discovered this issue back in 2018.

    You could try my workaround which i posted here. But be careful with this registry setting, it can open a security hole to your system.

    An error occurred while saving the comment
    Anonymous commented  · 

    We also try to use the Adobe PDF Reader ActiveX control in a 64-bit WPF app, but the app crashes every time when I try to move the cursor inside the control. The crash is caused by a BadImageFormatException when the CLR tries to load "comctl32.dll". The root cause of this problem is the embedded manifest in "AcroPDFImpl64.dll" which defines wrong values for processorArchitecture (X86).

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="Adobe Systems Inc.Acrobat.Adobe PDF Browser Control" type="win32"></assemblyIdentity>
    <description>Adobe PDF Browser Control.</description>
    <dependency>
    <dependentAssembly>
    <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
    </dependentAssembly>
    </dependency>
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
    <requestedPrivileges>
    <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
    </requestedPrivileges>
    </security>
    </trustInfo>
    </assembly>

    If I change the "PreferExternalManifest" registry setting and provide my own manifest as external file with correct values for processorArchitecture (amd64), then there is no crash anymore.

    But this change would have to much disadvantages to be usable in production environments.

    Is it possible to provide a correct version with the next Acrobat Reader Update?