none
Adobe Reader Crash [local install] when pulled into virtual environment RRS feed

  • Question

  • Good Afternoon:

    I'm experiencing a problem where, if an App-V 5 application opens a PDF, it pulls the locally installed Adobe Reader DC into the virtual environment and it causes a crash.  It isn't Adobe that crashes, though -- it's another application that launches with Adobe, RdrCef.exe.  This application is found in C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroCEF.

    If I start the RdrCef.exe outside of the virtual environment, everything seems fine.  I'm not really interested in Virtualizing Adobe Reader DC (even though Adobe has a great article on it!), but I am interested in using Adobe Reader DC with my other App-V applications.  Anyone else having problems?  Any suggestions on a workaround?

    I'm not entirely sure what RdrCEF actually does... but it can't be that important.  It throws the following series of error message, but then everything seems to be working fine.

    Thursday, March 17, 2016 8:29 PM

All replies

  • It's used for eServices, if you do not need it, disable it and check if the issue still occurs. Add the following policy:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown\cServices]
    "bToggleAdobeDocumentServices"=dword:00000001
    "bToggleAdobeSign"=dword:00000001
    "bTogglePrefSync"=dword:00000001
    "bUpdater"=dword:00000000


    Roy Essers

    Friday, March 18, 2016 12:02 AM
  • During sequencing did you have the Adobe Reader DC locally installed? I had a problem similar like this. I resequenced having the dependent application locally installed. Then it worked fine for me.


    (Please click on Vote as Helpful and/or Mark as Answer, if it has helped you.)

    app2pack.blogspot.com: app2pack.blogspot.com

    Friday, March 18, 2016 3:45 AM
  • @Roy

    I was excited to see these registry keys -- but after investigation, I've already defined all of them, and it still crashes. 

    @Vigneshwaran:

    Adobe Reader was not installed on the machine I was sequencing on.  

    An interesting note -- the exact same package work fine on Server 2008 R2.  If I open the virtual environment, then open a PDF inside it, Reader DC works fine.  If I move that same exact App-V package to a 2012 R2 machine and open the Virtual Environment, then open a PDF, I get the crashes.  Both machines are running App-V 5.1 HF2 for RDS...

    Friday, March 18, 2016 12:22 PM
  • I went old school with a fix for this.  

    It looks like there are two files that might be causing the issue:

    • "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroCEF\RdrServicesUpdater.exe"
    • "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroCEF\RdrCEF.exe"

    I tried to figure out what was going on, but didn't have much luck.  I renamed them both and -- no problems.  Everything seems to function well, and Adobe Reader DC even seems to start up a little quicker.

    Unless someone has a better solution, I'm putting in a group policy that just deletes these two files and calling it done!

    • Proposed as answer by Azhar_M Tuesday, May 22, 2018 9:13 AM
    Friday, March 18, 2016 5:58 PM
  • Renaming the files in my environment just result in the server remaking them upon launch of adobe reader.

    I do have a similar issue, and the settings mentions earlier here in registry I applied too, with the result of less errors, but it will still pop up at random users.

    my issue is that RdrCEF.exe crashes at random

    Wednesday, May 25, 2016 10:33 PM
  • Hi,

    I know this is an old thread, but I have the exact same issue. When Reader is pulled into the virtual environment, we get these error messages. So I renamed the RdrCEF.exe which makes that error not appear.

    However, when a user (or an admin for that matter) tries to save a document they opened in Adobe Reader, i.e. file --> save or file --> save as, only a white box appears. When I rename RdrCEF.exe back, I get the actual 'save' dialog again. Does anyone here have the same issue or maybe even a fix?

    Wednesday, May 9, 2018 9:13 AM
  • Can you try this method as explained by Andreas Nick.

    https://www.andreasnick.com/92-when-local-applications-are-started-by-app-v.html


    (Please click on Vote as Helpful and/or Mark as Answer, if it has helped you.)

    MVP - Windows and Devices for IT

    app2pack.blogspot.com: app2pack.blogspot.com

    Thursday, May 17, 2018 10:49 AM
  • Can you try this method as explained by Andreas Nick.

    https://www.andreasnick.com/92-when-local-applications-are-started-by-app-v.html


    (Please click on Vote as Helpful and/or Mark as Answer, if it has helped you.)

    MVP - Windows and Devices for IT

    app2pack.blogspot.com: app2pack.blogspot.com

    I've just had some time to test this. While it sounds plausible as well, it doesn't fix the issue from the opening post (error 0x00000142 and RdrCEF errors).

    As stated before, when renaming or denying acess to RdrCEF.exe, Reader works when pulled into the virtual environment, but the save dialog is not functional.

    So unfortunately, still no fix for us.

    [edit]

    While I was still playing around with it, I found that renaming or preventing access to RdrCEF breaks a lot of functionality actually. Like signing PDF's and pretty much every 'tool' if you wanted to use those anyway.

    So we really need a proper way to pull this into a virtual environment.
    Tuesday, May 22, 2018 9:47 AM
  • Hi All,

    I too was facing the same problem. I tried running AcroRD32.exe under Win7 compatibility mode and it fixed the issue. Adobe Reader works fine in the virtual bubble without any issues. So far the UAT seems to be successful.

    Hope this helps.

    Regards,

    Azhar.


    Azhar

    • Proposed as answer by Robert Gijsen Wednesday, May 23, 2018 9:12 AM
    Wednesday, May 23, 2018 8:54 AM
  • Hi All,

    I too was facing the same problem. I tried running AcroRD32.exe under Win7 compatibility mode and it fixed the issue. Adobe Reader works fine in the virtual bubble without any issues. So far the UAT seems to be successful.

    Hope this helps.

    Regards,

    Azhar.


    Azhar

    Sir,

    My hat's off to you! I never even though of trying compatibility settings, but in my first test it works like a charm! It's such a chame something so trivial as a PDF reader must be the monster they created with Adobe Reader. But at least it seems we can get this working now!

    • Proposed as answer by Azhar_M Tuesday, June 26, 2018 9:38 AM
    • Unproposed as answer by Azhar_M Tuesday, June 26, 2018 9:38 AM
    Wednesday, May 23, 2018 9:12 AM
  • When I package Adobe Reader DC, I find I must create a key in the package or the CEF program fails just after the GUI appears.  Procmon trace revealed that the process was trying to create a non-existent key and failing with a permission error.  Creating the key inside the package solved the issue.

    I believe notes on the key is given in this post (although the post is out of date for creating the full package): http://www.tmurgent.com/TmBlog/?p=2332 


    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (http://www.tmurgent.com/Books)

    Saturday, June 2, 2018 6:42 AM
    Moderator
  • Hmmm. As per https://www.andreasnick.com/92-when-local-applications-are-started-by-app-v.html (linked to in this thread) I tried with an exception fot the Adobe HKLM key, but that didn't work. The thing is, we don't package Adobe Reader, we install that locally. If the exclusion doesn't work, but creating the key in the package does work, that would mean I'd have to create that key in each application or connectiongroup. That would be a no-go either.

    If I find some time this week I'll still try that out though, just because I want to understand the issue. Setting compatibility mode works perfectly fine so far by the way, we have set that in production now, and everything's great!

    Monday, June 4, 2018 10:24 AM
  • It's been a while since I've used passthrough paths, but if the key exists in the bubble before the path is added, I believe you need to blow away the app-v content in the users profile in order to get it to apply.  This may have changed in newer versions... 

    I rely on passthroughpaths for a printer driver called Amyuni.  It's a PDF printer that can only be access programatically, and I had to add a few paths before it would work.  If it were not working, I'd have a couple thousand users screaming at me daily! In troubleshooting to find the right keys, I had to make an edit and reset the users app-v data for that package every time I tried a different key.

    With that said -- if you create the key outside of the bubble, say using a GPO to add it to machines, it should pass through to the bubble unless you have that key in your package set to replace whats on the local system.

    Thursday, June 7, 2018 2:52 PM
  • I've succesfully used the compatibility mode, and at the time I manually configured that on each server. However, I'm now trying to do that through GPO. I googled for those settings, and it seems we need to manually set some registry keys. I verified with Procmon and the only key/value that's set is

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
    "C:\\Program Files (x86)\\Adobe\\Acrobat Reader DC\\Reader\\AcroRd32.exe"="~ WIN7RTM"

    When I set that through GPO (or even by importing a regfile), when I go to the properties of the executable, the compatibility mode actually seems to be set. However it does NOT work from AppV. And yes I have rebooted in between just to be sure. I've checked with Procmon again whether AppV hooked the regkey and set something else but was unable to find that.

    Did anyone else run into this issue? Is there any other way, like running a rundll32 command or something to setup compatibility mode?

    Thursday, June 28, 2018 9:36 AM
  • A few months ago I ran into the problem that a locally installed Chrome did not work well when started in a specific virtual environment. It had to do with the virtual fonts subsystem. It was not an option for me to disable the virtual fonts. So I was happy to find another solution.

    Since a few weeks, (the package is used by more users now), I get complaints about a crashing Adobe Reader DC. Exactly as described in this topic. Again, disabling the virtual fonts subsystem solves the issue. Unfortunately the solution that works for Chrome.exe, does not work RdrCEF.exe.

    Thanks to Windows 10, fonts can be installed in user context. So, I created a simple script and added it to the UserConfig.xml. At publishing it writes the fonts and virtual font path to "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Fonts". And at unpublishing it removes those entries.

    Now I can disable my fonts subsystem in UserConfig.xml, Adobe Reader does not crash anymore, and my 'virtual' fonts are still available.


    Tuesday, July 30, 2019 2:23 PM