Microsoft Visual C++ Runtime Library runtime Error Adobe Reader 9.3.2.163

Question

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 9.3.2.163
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.
Thanks

Answer 1

There have been several similar topics over the last year or so; see this search result http://forums.adobe.com/search.jspa?q=runtime&resultTypes=MESSAGE&resultTypes=COMMUNITY&pe opleEnabled=true&dateRange=all&communityID=3414&username=&numResults=15&rankBy=10001
B_spies wrote:
I would post some attachments of our Process Monitor screenshots but attachments are apparently disabled on the forums right now.
You can still post images using the camera icon on the forum editor.