2 Replies Latest reply on Jun 21, 2010 7:59 PM by pwillener

    Microsoft Visual C++ Runtime Library runtime Error Adobe Reader


      I have not been able to find any posts that describe the problem I just uncovered, so that is why I am posting it here.


      Two errors seen so far:


      1 : In Internet Explorer 7, opening a PDF we get


      "Microsoft Visual C++ Runtime Llibrary" (title bar message)

      Runtime Error!

      Program: C:\Program Files\Internet Explorer\IEXPLORE.EXE

      abnormal program termination



      2: In Windows Explorer double click a PDF, or open Adobe Reader directly from the Start Menu


      "Microsoft Visual C++ Runtime Llibrary" (title bar message)

      Runtime Error!

      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 application's support team for more information



      This is working in our legacy Terminal Server environment.  We are migrating to a new Terminal Server environment using XenApp 5, and ran into this problem.  The big different is we are redirecting Application Data to a different path than we used to.  However, the old way was also a network UNC path (which I understand was a big problem in 7.0)


      We are running:

      32-bit Windows 2003 R2 SP2 Terminal Server

      Using Adobe Reader

      Using Application Data folder redirection to \\server\share\%username\folder\folder\Application Data

      *** The older legacy environment used \\server\%username\folder\folder\Application Data; as we wanted all user profiles to come in through a single share, which so far has been working fine. 


      The difference we have found is users do not have file permission to the root of the new single share.  for example for simplicities sake, lets say \\server\share is c:\users and under C:\users we have bjones, jdoe etc.  users have full control to their own folder, but not to c:\users.  Since the share maps to c:\users, \\server\share is actually not writable to users, but \\server\share\%username% is.  So far so good ...


      Except when analyzing what is going on before the crash (using sysinternals Process Monitor) I found the AcroRd32 does a little verification dance up the entire share and folder structure, creating and reading files and folders.  Because of this dance, and the lack of permissions I surmised it must be failing.  In Process Monitor I could see AcroRd32.exe checking the share, then my user folder then it dies with a "NAME COLLISION" because it tries to create a folder or file with the same name as one that already exists.  So I gave my test user account full control access to the entire structure and now my test account is working.


      So we are going to either abandon this idea or re-apply permissions to all our profile folders.  Not sure yet.


      I am more or less reporting this for others to benefit, and if Adobe can check into why their application feels like it must walk down the entire folder structure to verify it exists that would be an added bonus.