System.ArgumentException: Font '?' cannot be found. In the BootstapperApplication #5282

Closed
Braghar opened this Issue Apr 28, 2016 · 2 comments

Projects

None yet

3 participants

@Braghar
Braghar commented Apr 28, 2016
  • Which version of WiX are you building with?
    WiX Toolset v3.10.2
    wix-v3.10.2516.0
  • Which version of Visual Studio are you building with (if any)?
    VisualStudio 2013,
    Version 12.0.40629.00 Update 5
  • Which version of .NET are you building with?
    Version 4.6.01055
  • If the problem occurs when installing your packages built with WiX, what is the version of Windows the package is running on?
    Windows7 enterprise

We are creating an application, which has some .NET dependencies. To check these dependencies at setup time we use a BootstrapperApplication in the setup, which is a simple library.

The project is built successfully, the setup file is created, it can be started.

After starting the setup program of our application it hangs up after a while. The installer triggers the BootstrapperApplication and the Run method is called.
The problem is an exception: System.ArgumentException: Font '?' cannot be found. It comes at the first usage of SystemFonts (using direct or implicitly over an other API, it does not matter.)
The most simple way to get just use: var sdfsdf = SystemFonts.CaptionFont;

This problem did not come with Wix3.9. We used this version earlier and the problem comes just after changed to Wix3.10.

In the WixBootstrapper Bundle.wxs:

<BootstrapperApplicationRef  Id="ManagedBootstrapperApplicationHost">
  <bal:WixManagedBootstrapperApplicationHost LicenseFile="Resources\MicrosoftNet452EULA.rtf" LocalizationFile="Lang\2057\Texts.wxl" LogoFile="Resources\myprogram.bmp" />
  <Payload SourceFile="$(var.BinaryDir)Microsoft.Deployment.WindowsInstaller.dll" />

  <Payload Name="1031\Texts.wxl" SourceFile="Lang\1031\Texts.wxl" />
  <Payload Name="2057\Texts.wxl" SourceFile="Lang\2057\Texts.wxl" />

  <Payload SourceFile="$(var.TestLib.TargetPath)" />
  <Payload SourceFile="$(var.TestLib.TargetDir)log4net.dll" />
  <Payload SourceFile="$(var.TestLib.TargetDir)BootstrapperCore.config" />
  <Payload Name="de\sdf.resources.dll" SourceFile="$(var.SetupWixBootstrapperApplication.TargetDir)de\SetupWixBootstrapperApplication.resources.dll" />
</BootstrapperApplicationRef>

In the BootstrapperApplication, BootstrapperCore.config:

<configuration>
  <configSections>
    <sectionGroup name="wix.bootstrapper" type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperSectionGroup, BootstrapperCore">
      <section name="host" type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.HostSection, BootstrapperCore" />
    </sectionGroup>
  </configSections>

  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0" />
  </startup>

  <wix.bootstrapper>
    <host assemblyName="TestLib">
      <supportedFramework version="v4\Full" />
    </host>
  </wix.bootstrapper>

</configuration>

The BootstrapperApplication code:

namespace TestLib
{
    public class Class1 : BootstrapperApplication
    {
        protected override void Run()
        {
            try
            {
                var sdfsdf = SystemFonts.CaptionFont;
            }
            catch (Exception e)
            {
                Engine.Log(LogLevel.Error, "Caught Run exception: " + e);
            }
        }
    }
}

The exception:

System.ArgumentException: Font '?' cannot be found.
   at System.Drawing.FontFamily.GetGdipGenericSansSerif()
   at System.Drawing.FontFamily.get_GenericSansSerif()
   at System.Drawing.SystemFonts.get_DefaultFont()
   at System.Drawing.SystemFonts.get_CaptionFont()
   at TestLib.Class1.Run()
@barnson
Member
barnson commented Apr 28, 2016

Known issue, scheduled for fix in WiX v3.10.3.

@barnson barnson closed this Apr 28, 2016
@Braghar
Braghar commented Apr 29, 2016

Thank you for the quick answer!
Can you tell me when will be this version released?

@robmen robmen added bug burn labels May 3, 2016
@robmen robmen added this to the v3.10.3 milestone May 3, 2016
@robmen robmen self-assigned this May 3, 2016
@robmen robmen reopened this May 3, 2016
@robmen robmen added a commit to robmen/wix3 that referenced this issue May 3, 2016
@robmen robmen Workaround GDI+ security vulnerability
GDI+ fails in some scenarios when ::SetDefaultDllDirectories() is used
to protect a process from DLL hijacking. All WinForms based BAs hit this
problem. To workaround the failure, all Burn processes that load BAs
will no longer protect themselves from DLL hijacking. In particular, the
clean room and package cache processes will be unsecure. Fortunately,
the design of those processes should be safe without the extra
protection.

Fixes wixtoolset/issues#5282
6cdbec5
@robmen robmen referenced this issue in wixtoolset/wix3 May 3, 2016
Closed

Workaround GDI+ security vulnerability #351

@robmen robmen added a commit to robmen/wix3 that referenced this issue May 4, 2016
@robmen robmen Workaround GDI+ security vulnerability
GDI+ fails in some scenarios when ::SetDefaultDllDirectories() is used
to protect a process from DLL hijacking. All WinForms based BAs hit this
problem. To workaround the failure, the clean room process which load
BAs will no longer protect itself from DLL hijacking because it should
be secure due to its design. Additionally, the package cache processes
will launch a clean room even though it is technically already secure to
keep processing consistent.

Fixes wixtoolset/issues#5282
5b95def
@robmen robmen added a commit to robmen/wix3 that referenced this issue May 6, 2016
@robmen robmen Workaround GDI+ security vulnerability
GDI+ fails in some scenarios when ::SetDefaultDllDirectories() is used
to protect a process from DLL hijacking. All WinForms based BAs hit this
problem. To workaround the failure, the clean room process which load
BAs will no longer protect itself from DLL hijacking because it should
be secure due to its design. Additionally, the package cache processes
will launch a clean room even though it is technically already secure to
keep processing consistent.

Fixes wixtoolset/issues#5282
825c8b8
@robmen robmen added a commit to robmen/wix3 that referenced this issue May 6, 2016
@robmen robmen Workaround GDI+ security vulnerability
GDI+ fails in some scenarios when ::SetDefaultDllDirectories() is used
to protect a process from DLL hijacking. All WinForms based BAs hit this
problem. To workaround the failure, the clean room process which load
BAs will no longer protect itself from DLL hijacking because it should
be secure due to its design. Additionally, the package cache processes
will launch a clean room even though it is technically already secure to
keep processing consistent.

Fixes wixtoolset/issues#5282
6afae67
@rseanhall rseanhall added a commit to wixtoolset/wix3 that closed this issue May 16, 2016
@robmen @rseanhall robmen + rseanhall Workaround GDI+ security vulnerability
GDI+ fails in some scenarios when ::SetDefaultDllDirectories() is used
to protect a process from DLL hijacking. All WinForms based BAs hit this
problem. To workaround the failure, the clean room process which load
BAs will no longer protect itself from DLL hijacking because it should
be secure due to its design. Additionally, the package cache processes
will launch a clean room even though it is technically already secure to
keep processing consistent.

Fixes wixtoolset/issues#5282
5afbce0
@rseanhall rseanhall added a commit to wixtoolset/wix3 that referenced this issue May 16, 2016
@robmen @rseanhall robmen + rseanhall Workaround GDI+ security vulnerability
GDI+ fails in some scenarios when ::SetDefaultDllDirectories() is used
to protect a process from DLL hijacking. All WinForms based BAs hit this
problem. To workaround the failure, the clean room process which load
BAs will no longer protect itself from DLL hijacking because it should
be secure due to its design. Additionally, the package cache processes
will launch a clean room even though it is technically already secure to
keep processing consistent.

Fixes wixtoolset/issues#5282
17c6d94
@rseanhall rseanhall added a commit to rseanhall/wix4 that referenced this issue Sep 25, 2016
@robmen @rseanhall robmen + rseanhall Workaround GDI+ security vulnerability
GDI+ fails in some scenarios when ::SetDefaultDllDirectories() is used
to protect a process from DLL hijacking. All WinForms based BAs hit this
problem. To workaround the failure, the clean room process which load
BAs will no longer protect itself from DLL hijacking because it should
be secure due to its design. Additionally, the package cache processes
will launch a clean room even though it is technically already secure to
keep processing consistent.

Fixes wixtoolset/issues#5282
323def1
@robmen robmen added a commit to wixtoolset/wix4 that referenced this issue Jan 7, 2017
@robmen robmen Workaround GDI+ security vulnerability
GDI+ fails in some scenarios when ::SetDefaultDllDirectories() is used
to protect a process from DLL hijacking. All WinForms based BAs hit this
problem. To workaround the failure, the clean room process which load
BAs will no longer protect itself from DLL hijacking because it should
be secure due to its design. Additionally, the package cache processes
will launch a clean room even though it is technically already secure to
keep processing consistent.

Fixes wixtoolset/issues#5282
758a174
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment