Jump to content
Welcome to our new Citrix community!
  • 0

Application crashes after installing 7.x VDA


Chris Radi

Question

We are building a new XenApp 7.6 LTSR CU1 environment, upgrading from our horribly outdated v5 setup.  I've run into one application that works great, until I install the VDA.  After installing the VDA, the application crashes immediately after launch, reporting an exception in MSVCR120.dll (MS Visual ++ runtime 2013).  I have tried everything I can think of to resolve the problem, but am out of ideas.  We setup a test 6.5 farm yesterday, and the application works fine, and has always worked under 4.5/5.0.  If I remove just the VDA (leaving all the pre-reqs in place), the application works again.  We have tried:

  • Disabling Citrix API hooks for the executables using ExcludedImageNames (https://support.citrix.com/article/CTX107825)
  • Disabling all hooks by setting the Flags value to 0 (both x64 and x86 keys)
  • Disabling all hooks by deleting all the keys under HKLM\Software\Citrix\CtxHook
  • Setting HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\LoadAppInit_DLLs = 0
  • Removed antivirus
  • Rebuilt clean VM with just this application and the VDA
  • Disabled UAC and/or run the application as an administrator
  • Disabled all GPOs
  • VDA versions 7.5, 7.6 LTSR CU1, 7.8 and 7.9, including before and after installing available hotfixes.
  • Copious amounts of gin
  • Ritual intern sacrifice

The application crashes regardless of the session type (ICA, RDS, or console).  It's not a common application (New World Systems Aegsi MSP 10.2)  so I can't find anyone else reporting success or failure with it.  The application works fine under plain RDS, as long as the VDA is not installed.

 

At this point, we're starting to working a new 6.5 farm, just for users that need this application; however, I'd much prefer to have everyone on the same version.

Link to comment

14 answers to this question

Recommended Posts

  • 1

Just wanted to share my experience here.  I recently implemented a new Xendesktop 7.15 system for a company that uses the New World applications.  I experienced the exact same application crashes related to the msvcr120.dll.    The 7.15 VDA requires both C++ 2013 and C++ 2014.  I contacted Tyler Technologies and they weren't much help, but did indicate that their applications don't require the C++ redistributable.  Of course that didn't explain why the applications was crashing once it was installed.  Long story short, this is what I have done to work around the situation.  I created a local group on the VDI master image named Citrix Administrators and then people to that group that would be accessing the workstation without needing to run the New World applications.  After that, I modified the security on the c:\windows\syswow64\msvcr120.dll file to limit permissions to only the system and the Citrix Administrators account.  That appears to have made it possible for the VDA and Citrix services and applications to run and still allow the New World applications to work as well.   Hope this helps someone else.

  • Like 1
Link to comment
  • 1

To reply to my own question, I think I've figured out an FSLogix rule that works.  We have not done much testing yet.  This setup it seems to allow Aegis LE Records and Fire Records to run without interfering with Adobe Reader or other applications.

  1. Create a hiding rule to hide this file:  C:\Program Files (x86)\Citrix\System32\wfapi.dll
  2. Create a hiding rule to hide this file:  C:\Program Files (x86)\Citrix\System32\wfapi64.dll
  3. Apply the rule to C:\Program Files (x86)\New World Systems\Aegis MSP\AegisLerms.exe, including child processes
  4. Apply the rule to C:\Program Files (x86)\New World Systems\Aegis MSP\AegisFire.exe, including child processes
  • Like 1
Link to comment
  • 0

Hi Chris.

 

We are having the exact same problem with the same New World Applications. I was wondering if you ever found a fix for this. I'm out of ideas as well. It just seems to be 7.6 - 7.11 VDA and New World Applications (Aegis LERMS, Aegis Fire, Aegis Corrections, etc...). No other application has this problem. New World says they don't support Citrix.

Link to comment
  • 0
On 12/13/2017 at 2:48 PM, Karl Miller1709152784 said:

Just wanted to share my experience here.  I recently implemented a new Xendesktop 7.15 system for a company that uses the New World applications.  I experienced the exact same application crashes related to the msvcr120.dll.    The 7.15 VDA requires both C++ 2013 and C++ 2014.  I contacted Tyler Technologies and they weren't much help, but did indicate that their applications don't require the C++ redistributable.  Of course that didn't explain why the applications was crashing once it was installed.  Long story short, this is what I have done to work around the situation.  I created a local group on the VDI master image named Citrix Administrators and then people to that group that would be accessing the workstation without needing to run the New World applications.  After that, I modified the security on the c:\windows\syswow64\msvcr120.dll file to limit permissions to only the system and the Citrix Administrators account.  That appears to have made it possible for the VDA and Citrix services and applications to run and still allow the New World applications to work as well.   Hope this helps someone else.

 

OMG! I want to thank you soo much! that worked! @Karl Miller1709152784

Link to comment
  • 0

Since others seem to be having this same issue, I wanted to post a solution that we figured out recently.  Building on the @Karl Miller1709152784 solution, I tried using App-V to eliminate the msvcr120.dll library that way.  Simply sequencing the installation wasn't enough; however, as part of sequencing Aegis MSP, we replaced the mscvcr120.dll in SysWow64 with an empty (0 byte) file and included that in the package.  We're now able to push this App-V package to our XenApp 7x systems, and both Aegis MSP Fire and LERMS run correctly.  Since msvcr120.dll is unmodified, other applications that need it still run correctly.

Link to comment
  • 0

I opened cases with both Microsoft and Citrix on this issue.  When I sent crash dumps for analysis - this is what I heard back from Citrix:

 

Quote

 

Please advise customer that application vendor need to be contacted – they use Citrix WinFrame API function with NULL parameter.

The crash happen in Citrix WinFrame API function WFOpenServerA()  while calling mbstowcs() with second parameter – mbstr – NULL. Actually they call with NULL string instead of server name as well which caused the crash. So it looks like application issue – wrong use of Winframe API.

 

 

And, Microsoft's analysis:

 

Quote

 

Working along with debugging team, we were able to determine that the problem is happening when AegisLerms calls to open a citrix server that we have no access to see.

 

Please share the following analysis with citrix so they can proceed to determine the problem in their end:

 

STACK:

We see that the call made to msvcr120 (C runtime library) is made by a citrix dll called wfapi.
wfapi then calls WFOpenServerA, somewhere inside that function, mbstowcs is called.
When the parsing is done by mbstowcs, the following exception occurs:
 
ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
 
Microsoft has no knowledge on what WFOpenServerA does, since this is a Citrix Module, 

 

On Frame 7 0019fbc4 034fe7bf AegisLerms+0x310708e:
 
Your Aegis software is performing a call which we cannot see because we do not have symbols. This call somehow ended up calling a Citrix module.
This could have happened intentionally (if your application calls a Citrix module) or if the Citrix component installed has hooked into the call which you are performing.
 
After this occured, the Citrix module wfapi called WFOpenServerA+0x29.
 
This Citrix function, in turn, called the msvcr120 (C runtime Library) to perform a multi-byte to character conversion (mbstowcs). When performing this conversion, the fault occurs.

 

Additionally we found that the application is based in visual basic 6.0, it will be recommended to have it updated, please discuss this information with the application vendor.

 

 

 

We've not been able to get any traction from Tyler on this either - with them stating: "Holistically, we don’t support Citrix....."

 

I've not been able to get any of the solutions in this thread to work, since upgrading to the 1906.1 VDA.  The app still crashes in a similar manner, but now ucrtbase.dll is faulting instead of msvcr120.dll

 

Quote

Faulting application path: C:\Program Files (x86)\New World Systems\Aegis MSP\AegisLerms.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll

 

We're supposed to be getting an upgrade to New World this summer - but I don't believe they will be addressing this at all....

 

Curious to see if anyone else has upgraded to the later VDA (1906) - to see how you are handling this.

 

 

 

Link to comment
  • 0

@Ben Smith1709160361 Great info! We were able to get it working for the most part using @Karl Miller1709152784 's solution. The problem is Adobe Reader uses that library as well, so that broke. We purchesed FSLogix App Masking which seemed to fix it by isolating the use of the dll file. Adobe Reader worked fine on the same machine, however, when LERMS calls Adobe Reader directly (they actually call AcroRd32.exe directly) it says the VS C++ redistributable isn't installed.  ... So deeper down the rabbit hole. Cloudhouse thinks they can fix the issue, however it would take a monetary commitment for their time to try.

Link to comment
  • 0

Would you mind sharing details on how you setup your FSLogix rules?  I've been testing it out, and while I've been able to block msvcr120.dll, Aegis LERMS opens but gets held up before I get to the login screen.  I'm also going to try masking some Citrix DLLs or folders, instead of msvcr120.dll, as according to the MS from @Ben Smith1709160361, it seems like those are the real issues, not Visual C++.

 

In case some are not aware, FSLogix was purchased by Microsoft and the product is now free to clients with SA on their RDS CALs.  We're already working on implementing it to replace UPM, and it's been pretty awesome.

Link to comment
  • 0

Nice - worked good for me so far, the app does not crash with the rule applied.  :)

 

What OS is your VDA installed on?   It appears that LERMS crashes for us when installing on Server 2016 or 2019.  The app will open but as soon as the user tries a transaction it crashes.  Will be trying Server 2012 tomorrow to see if that makes a difference.   Tyler does not list any Windows Server product as supported, although we've been running it on 2008 R2 for years..

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...