locked
App-V 5 Java App Random Crashes RRS feed

  • Question

  • Hi

    We’re deploying Windows 10 1709 64-bit in conjunction with App-V and having problems with a troublesome Java app. If we install the app natively it works perfectly, however, in App-V the app takes much longer to launch (once fully cached) and crashes intermittently when launched with Java exit code 1073740940.

    The app is fairly simple in that it has a built in JRE and no registry at all. It is fairly large though, about 1GB.

    I’ve tried researching the Java error code but it seems to be a generic one and haven’t come across anything to direct me towards a possible solution.

    In terms of Sequencing, we’ve tried VFS, PVAD, all combinations of the check boxes on the advanced tab (write VFS etc). We’ve tried sequencing on Win7/win10. The app writes various dlls etc into the user profile when it’s launched so we’ve tried including/excluding [{Profile}] during sequencing (only works with the latter). We’ve tried launching/not launching the app during sequencing. Tried using the latest JRE, messing with heap size settings (found some suggestions that the java error is related to this). Tried different App compatibility settings.

    The annoying thing is it works most of the time but randomly crashes when launching from time to time. In addition to the Java exit code above an error appears in Eventvwr always the same:

    Faulting application name: javaw.exe, version: 8.0.720.15, time stamp: 0x567a0cdd

    Faulting module name: ntdll.dll, version: 10.0.16299.248, time stamp: 0x3a21d961

    Exception code: 0xc0000374

    Fault offset: 0x000da879

    Faulting process ID: 0x4c0

    Faulting application start time: 0x01d3f98002eee292

    Faulting application path: C:\ProgramData\App-V\65366493-438F-44B9-BE0F-60F90ABD4440\1832F2DB-F6B8-4E17-850C-62880AC48E0E\Root\jre\bin\javaw.exe

    Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll

    Report ID: c6bc23e5-0fb0-4609-9db9-3f7f1169ce32

    Faulting package full name:

    Faulting package-relative application ID:

    I’ve used procmon to try and look for any patterns prior to the app crashing but come up with nothing. I’ve also cached the app on a vanilla Win10 device with no policies or security products or other apps to rule that out and get the same result.

    Can anyone offer any advice on options to try and get this thing working? It’s going to create a headache if we can’t get the particular app virtualized so really keen to get to the bottom of it. I’m struggling to think of what else to try now.

    Thanks in advance.

    Friday, June 1, 2018 10:20 AM

All replies

  • Generically, Java runs very well and stable under App-V, and there is very little you need to do when packaging it up.  Certainly none of the things you mentioned are needed.  You do need to disable updates (in the control panel applet after install, or just import the registry setting for it).  Possibly enabling VFS writes can be needed by the java web app, but that is unlikely.

    I usually ensure some registry keys are pre-created, and use a blocking technique to ensure I get the version of Java that I intend to use.  A newer version of java deployed natively would be found if you don't.  See this blog post: http://www.tmurgent.com/TmBlog/?p=2235 on details on how to block newer Java versions.


    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:33 AM
    Moderator
  • Generically, Java runs very well and stable under App-V, and there is very little you need to do when packaging it up.  Certainly none of the things you mentioned are needed.  You do need to disable updates (in the control panel applet after install, or just import the registry setting for it).  Possibly enabling VFS writes can be needed by the java web app, but that is unlikely.

    I usually ensure some registry keys are pre-created, and use a blocking technique to ensure I get the version of Java that I intend to use.  A newer version of java deployed natively would be found if you don't.  See this blog post: http://www.tmurgent.com/TmBlog/?p=2235 on details on how to block newer Java versions.


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

    Hi Tim

    Thanks for your response. I've packaged various versions of JRE historically following your blog guidance and that's normally been my experience too. The difference with this app is it's one of these where it has a copy of the java bin and libraries wrapped up in the installer, I'm not actually installing the runtime myself. The app is configured to reference the JRE that's located within its own installation directory and doesn't run in IE. As such I'm not sure this app would suffer from the issue of conflicting with a native JRE but the plan is also not to run any native JRE on this build.

    When I tested using the latest JRE available I installed it on another machine and copied the relevant bin/lib folders into the app root during the sequence. The app worked but sadly it didn't fix the crash.

    One thing I have noticed is that when I use the /appvve: switch to load an explorer or iexplore process within an app bubble (of any app), the explorer or IE process in the bubble seems to perform very sluggishly or come up 'not responding'. I only see this with IE or explorer though, if I launch notepad and browse the VFS that way it works fine, for example. 

    I wondered whether it might be related to dynamic virtualization so disabled this but it had no effect. Using procexp I can see explorer spawning several Shell32.exe processes which seem to consume a lot of CPU cycles. I also saw ntdll.dll being referenced frequently by explorer so wondered whether this behaviour might be related to my java problem being as that's the faulting module in the error.

    Have you ever seen this kind of behaviour?

    Thanks


    • Edited by Stewmang Saturday, June 2, 2018 7:31 AM Typo
    Saturday, June 2, 2018 7:30 AM
  • Generically, Java runs very well and stable under App-V, and there is very little you need to do when packaging it up.  Certainly none of the things you mentioned are needed.  You do need to disable updates (in the control panel applet after install, or just import the registry setting for it).  Possibly enabling VFS writes can be needed by the java web app, but that is unlikely.

    I usually ensure some registry keys are pre-created, and use a blocking technique to ensure I get the version of Java that I intend to use.  A newer version of java deployed natively would be found if you don't.  See this blog post: http://www.tmurgent.com/TmBlog/?p=2235 on details on how to block newer Java versions.


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

    Hi Tim

    Thanks for your response. I've packaged various versions of JRE historically following your blog guidance and that's normally been my experience too. The difference with this app is it's one of these where it has a copy of the java bin and libraries wrapped up in the installer, I'm not actually installing the runtime myself. The app is configured to reference the JRE that's located within its own installation directory and doesn't run in IE. As such I'm not sure this app would suffer from the issue of conflicting with a native JRE but the plan is also not to run any native JRE on this build.

    When I tested using the latest JRE available I installed it on another machine and copied the relevant bin/lib folders into the app root during the sequence. The app worked but sadly it didn't fix the crash.

    One thing I have noticed is that when I use the /appvve: switch to load an explorer or iexplore process within an app bubble (of any app), the explorer or IE process in the bubble seems to perform very sluggishly or come up 'not responding'. I only see this with IE or explorer though, if I launch notepad and browse the VFS that way it works fine, for example. 

    I wondered whether it might be related to dynamic virtualization so disabled this but it had no effect. Using procexp I can see explorer spawning several Shell32.exe processes which seem to consume a lot of CPU cycles. I also saw ntdll.dll being referenced frequently by explorer so wondered whether this behaviour might be related to my java problem being as that's the faulting module in the error.

    Have you ever seen this kind of behaviour?

    Thanks


    Partial update on the issue I mentioned above about high resource usage when launching explorer.exe within virtual environments. I've discovered that this issue only occurs after installing KB4074588. I've tested this on a 1709 machine with no CU installed and it works perfectly. As soon as I install the CU I see the slow performance and high CPU usage in explorer. I was incorrect when I said it also impacts iexplore.exe though, I was navigating to the local file system from within IE when I tried this which of course invokes explorer.

    Sadly, however, the Java issue still persists on a machine without the CU installed, but at least I've been able to establish that the two issues don't appear to be related.

    Saturday, June 2, 2018 1:25 PM
  • Partial update on the issue I mentioned above about high resource usage when launching explorer.exe within virtual environments. I've discovered that this issue only occurs after installing KB4074588. I've tested this on a 1709 machine with no CU installed and it works perfectly. As soon as I install the CU I see the slow performance and high CPU usage in explorer.

    That's a know issue with dynamic virtualization, which also delays the start of explorer if you have apps which need to hook (notepad++ for example). I've an open ticket about this issue, and a CU is scheduled for this month. 

    Roy Essers

    Sunday, June 3, 2018 9:23 AM
  • This should be same issue reported on the other thread, that there are some kernel regression started 1709 caused unusually long loading time for appv detours.
    Monday, June 4, 2018 4:44 PM
  • To update on the main topic of this thread, the Java crashing issue was fixed by running the app in Vista compatibility mode. I have no idea why as the same app runs perfectly on the same OS installed natively, but this change has completely eradicated the crashes.
    Tuesday, June 12, 2018 12:25 PM
  • Partial update on the issue I mentioned above about high resource usage when launching explorer.exe within virtual environments. I've discovered that this issue only occurs after installing KB4074588. I've tested this on a 1709 machine with no CU installed and it works perfectly. As soon as I install the CU I see the slow performance and high CPU usage in explorer.

    That's a know issue with dynamic virtualization, which also delays the start of explorer if you have apps which need to hook (notepad++ for example). I've an open ticket about this issue, and a CU is scheduled for this month. 

    Roy Essers


    I stil see this issue with Dynamic Virtualisation disabled so not sure it's the same problem.
    Tuesday, June 12, 2018 12:25 PM
  • This should be same issue reported on the other thread, that there are some kernel regression started 1709 caused unusually long loading time for appv detours.

    Is the other thread this one? If so is it definitely the same issue as that user appears to be having issues launching explorer natively rather than from within a virtual environment. Running explorer natively works fine for me.

    Also when you say the issue is since 1709, I don't see the problem with explorer hanging on a 1709 machine with no CU, only once KB4074588 is installed.

    Is there a plan to release a hotfix for these issues or will it be addressed in this month's CU?

    Thanks

    Tuesday, June 12, 2018 12:31 PM
  • It will be included in the CU for next week, not today (12th June)

    Roy Essers

    Tuesday, June 12, 2018 9:32 PM
  • Friday, June 22, 2018 8:07 AM