none
wpfgfx_v0400.dll missing from latest windowsservercore be84290c2315 RRS feed

  • Question

  • With the latest container, image ID be84290c2315, I am seeing that my application no longer runs.

    This application is a scriptable version of a full Wpf application. No Wpf windows are shown during a scripted session.

    When using the latest container image, the application throws an exception indicating that the wpfgfx_v0400.dll could not be loaded. Using windowsservercore:10.0.14393.1358 allows the same application to run without error.

    I understand that Server Core doesn't have a user interface and shouldn't be considered a hosting O/S for one. However was there an explicit decision to remove the wpfgfx_v0400.dll?

    Friday, September 1, 2017 1:24 PM

All replies

  • I'm still seeing C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\wpfgfx_v0400.dll in windowsservercore:latest. Are you targeting .NET 4.0+ with your WPF application?

    Monday, September 4, 2017 5:43 AM
  • I must admit I didn't look in the actual file system of the container. The application is targeting .NET Framework 4.6.1. Console Application and uses Caliburn.Micro 3.0.3.

    The following is the exception details:

    Unhandled exception The type initializer for '<Module>' threw an exception.
    System.TypeInitializationException: The type initializer for '<Module>' threw an exception. ---> <CrtImplementationDetails>.ModuleLoadException: The C++ module failed to load during appdomain initialization.
     ---> System.DllNotFoundException: C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\wpfgfx_v0400.dll ---> System.ComponentModel.Win32Exception: The specified module could not be found
       --- End of inner exception stack trace ---
       at MS.Internal.NativeWPFDLLLoader.LoadNativeWPFDLL(UInt16* relDllPath, UInt16* baseDllPath)
       at MS.Internal.NativeWPFDLLLoader.LoadCommonDLLsAndDwrite()
       at CModuleInitialize.{ctor}(CModuleInitialize* , IntPtr cleaningUpFunc)
       at ?A0x4676cc04.CreateCModuleInitialize()
       at ?A0x4676cc04.??__E?A0x4676cc04@cmiStartupRunner@@YMXXZ()
       at _initterm_m((fnptr)* pfbegin, (fnptr)* pfend)
       at <CrtImplementationDetails>.LanguageSupport.InitializePerAppDomain(LanguageSupport* )
       at <CrtImplementationDetails>.LanguageSupport._Initialize(LanguageSupport* )
       at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* )
       --- End of inner exception stack trace ---
       at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* )
       at .cctor()
       --- End of inner exception stack trace ---
       at Caliburn.Micro.View.get_InDesignMode()
       at Caliburn.Micro.XamlPlatformProvider.get_InDesignMode()
       at Caliburn.Micro.BootstrapperBase.Initialize()

    I am using the BootStrapperBase class constructor with useApplication parameter of false.

    Switching to an earlier version of the container image and the software unchanged runs without this exception.

    Monday, September 4, 2017 9:03 AM
  • Yes we are having a similar issue. A .NET 4.6.2 application using the microsoft/dotnet-framework:4.6.2 image which currently is built off microsoft/windowsservercore:10.0.14393.1593. It appears that the Windows Server Core build is the problem.

    A workaround for now is to build the docker images from microsoft/dotnet-framework:4.6.2-windowsservercore-10.0.14393.1480.

    Wednesday, September 6, 2017 11:08 AM
  • This issue isn't isolated to containers. I just got this same error yesterday with an app that is running on a server core vm. I had to switch over to use the TFS SDK instead of the REST API so that we could implement impersonation. This error popped up when I deployed my changes to the server. The vm is on version 10.0.14393 N/A Build 14393. The interesting part is that I have verified the dll is actually there. I have no idea why it wouldn't be able to find it.

    System.TypeInitializationException: The type initializer for '<Module>' threw an exception. ---> <CrtImplementationDetails>.ModuleLoadException: The C++ module failed to load during appdomain initialization. ---> System.DllNotFoundException: C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\wpfgfx_v0400.dll ---> System.ComponentModel.Win32Exception: The specified module could not be found --- End of inner exception stack trace --- at MS.Internal.NativeWPFDLLLoader.LoadNativeWPFDLL(UInt16* relDllPath, UInt16* baseDllPath) at MS.Internal.NativeWPFDLLLoader.LoadCommonDLLsAndDwrite() at CModuleInitialize.{ctor}(CModuleInitialize* , IntPtr cleaningUpFunc) at ?A0x4676cc04.CreateCModuleInitialize() at ?A0x4676cc04.??__E?A0x4676cc04@cmiStartupRunner@@YMXXZ() at _initterm_m((fnptr)* pfbegin, (fnptr)* pfend) at <CrtImplementationDetails>.LanguageSupport.InitializePerAppDomain(LanguageSupport* ) at <CrtImplementationDetails>.LanguageSupport._Initialize(LanguageSupport* ) at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* ) --- End of inner exception stack trace --- at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* ) at .cctor() --- End of inner exception stack trace --- at Microsoft.VisualStudio.Services.Client.ClientNativeMethods.GetDefaultParentWindow() at Microsoft.VisualStudio.Services.Client.Controls.VssCredentialPrompts.CreatePromptsWithHost(WindowsCredential windowsCredential, FederatedCredential federatedCredential, IDialogHost host) at Microsoft.VisualStudio.Services.Client.VssClientCredentials.LoadCachedCredentials(String featureRegistryKeyword, Uri serverUrl, Boolean requireExactMatch, CredentialPromptType promptType) at Microsoft.TeamFoundation.Client.TfsClientCredentialsCache.GetCredentials(String featureRegistryKeyword, Uri uri) at Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory.GetTeamProjectCollection(String featureRegistryKeyword, Uri uri) at MyProject.Api.ApiServices.Tfs.TfsContext.GetTeamProjectCollection(String useremail) at MyProject.Api.ApiServices.Tfs.TfsContext.GetWorkItemStore(String useremail) at MyProject.Api.Bugs.TfsBugsQueryService.RunQuery(String Query) at MyProject.Api.Bugs.TfsBugsQueryService.<GetPublishedRecentlyReported>d__14.MoveNext()


    Wednesday, September 6, 2017 1:16 PM
  • I think the issue is the DLL is missing a native dependency.
    Wednesday, September 6, 2017 1:34 PM
  • This is a bug in the .NET runtime installed in microsoft/windowsservercore:10.0.14393.1198, fixed in microsoft/windowsservercore-insider builds. (I tested 10.0.16278.1000, might be fixed in earlier insider builds.)

    When showing graphics via WPF, the runtime spins up and attempts to load d3dcompiler_47.dll which is missing from the base image.

    Workaround:

    1. Grab the KB4020302 update for Windows Server 2012 http://go.microsoft.com/fwlink/?LinkId=848160
    2. Open a command prompt wherever you downloaded the MSU
    3. mkdir %temp%\kb4019990
    4. expand -f:* Windows8-RT-KB4019990-x64.msu %temp%\kb4019990
    5. expand -f:* %temp%\kb4019990\Windows8-RT-KB4019990-x64.cab %temp%\kb4019990

    If your app is 32-bit, deploy your app with the library in [x86_microsoft-windows-directx-d3dcompiler_31bf3856ad364e35_6.2.9200.22158_none_e6ab00aa06791aa5]

    If your app is 64-bit, deploy your app with the library in [amd64_microsoft-windows-directx-d3dcompiler_31bf3856ad364e35_6.2.9200.22158_none_42c99c2dbed68bdb]



    • Proposed as answer by WithinRafaelMVP Wednesday, September 6, 2017 5:26 PM
    • Edited by WithinRafaelMVP Wednesday, September 6, 2017 5:27 PM Fixed formatting
    Wednesday, September 6, 2017 5:26 PM
  • @WithinRafael I tried this and it didn't seem to make a difference. I placed the d3dcompiler_47.dll in c:\Windows\System32. Is that not the right location? What do you mean by "deploy your app with the library"? 
    Friday, September 8, 2017 8:47 PM
  • Is your app 32-bit or 64-bit? By deploy with your app, I mean drop it into the same directory with your app's executable.
    Friday, September 8, 2017 9:18 PM