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

  • Article

"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.