Udostępnij za pośrednictwem

App-V 5.0: On these 0xc0000142 errors and where they are coming from.

  • Artykuł

"Where are these 0xc0000142 errors coming from in App-V 5.0?"

There has been some chatter revolving around this generic application error that is happening with many LOB (Line of Business applications) running virtualized with App-V 5.0. You will also note that for a lot of these applications, this issue did not occur in previous versions of App-V. The error is as follows:

The application was unable to start correctly (0xc0000142). Click OK to close the application.

First of all, this is not an App-V error but rather a generic application error. Does this mean that App-V did not play some role in it? No. Obviously that would not be the case if the application behaved fine prior to virtualization. So in order to isolate what App-V’s role is, we need to understand first what the error means.

This error (0xc0000142) technically resolves to STATUS_DLL_INIT_FAILED in the native API – which simply means that it was unable to load or initialize a critical DLL, etc. If there is a DLL mismatch or some other type of subsystem failure, you will get this error. If the DLL can be found and loads but fails to initialize, you will also get this error.

I know of one type of application where you may find this most prevalent. In one specific type of use case, there may be applications that are written with client-side “bootstrap” executables. These executables then load server-side modules over the network. These applications were written to allow for ease of updating on the back end. In App-V 4.x, when these applications loaded these modules, they would be impersonated on behalf of the user so the user just needed to have read and execute permissions to access these modules over the network. Even under App-V 4.x, these modules would be brought into the bubble under the context of the current user account.

In App-V 5.0, the App-V Client is running as system, which means file operations will operate under the AppVClient.exe process which will be running under the context of the local system account and not the user account. Even though the executable is loaded into the context of the user running the program, the file operation will be spearheaded by the AppVClient.exe process and the access will not be impersonated. So in the case of these 0xc0000142 errors, it is likely because there is a file operation that is occurring under the system account. It will fail authentication, thus preventing the loading of the DLL causing this error.

How do I know if this is the case?

Once again Process Monitor will be your friend. It will involve a very simple procedure to isolate this. First reproduce the issue while capturing the events with Process Monitor. Once you have done that all you need to do is apply a quick filter to see if, in fact, the AppVClient.exe is getting a logon error when trying to access the share where the DLLs are located. The events you need to filter for are:

  • Process Name: AppVClient.exe
  • Operation: Create File
  • Result: LOGON FAILURE

 So what do I do now?

You can resolve these errors by granting access (RX) to the directory for the computers accessing the shares as SYSTEM. Bear in mind they will need that at both the share level and the NTFS level. As of now, that appears to be the best point of remediation.

Comments

  • Anonymous
    January 01, 2003
    Not as this time, no.

  • Anonymous
    January 01, 2003
    Hi Steve, thanks for this article. Is there any news about this issue? It seems that the 'problem' isn't solved with App-V 5 SP2.

  • Anonymous
    December 06, 2013
      Hi Steve, I created an app-v  package with dependencies (oracle client, borland database engine) and I need to load it and then run an .exe on a network share. The user list using this application is huge and I can't put "domain computers" on the network share for security concerns. Is there another workaround, maybe in a future release?

  • Anonymous
    December 08, 2013
    The team has received much feedback on this and will be examining options for the future.

  • Anonymous
    January 15, 2014
    Hi Steve, we too have this issue. Its not practical to be applying share and NTFS permissions for each network application we have. It's also a security issue/concern as well. Any further update on this?

  • Anonymous
    June 30, 2015
    ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like

  • Anonymous
    June 30, 2015
    ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like

  • Anonymous
    September 28, 2016
    We are facing the same error now with AppV 5.1. Some of the IT guys told me, that there is an issue with NtfsDisable8dot3NameCreation value in registry. https://support.microsoft.com/de-ch/kb/2777003We have different states of this registry value. On some computers the appv runs and on some not. This is kind of weird. Doesn't make sense to me at all.

  • Anonymous
    July 05, 2017
    I have that problem now with a Firefox Package:First time starting the package is ok, second time too, and so on.Unpublish / replublish:No more starting of firefox, 0xc0000142 error :(