Custom burn application throws exception when accessing .NET dll when uninstalling #5308

Closed
slynch8 opened this Issue May 26, 2016 · 10 comments

Projects

None yet

4 participants

@slynch8
slynch8 commented May 26, 2016
  • Which version of WiX are you building with?

v3.10.3.2924

  • Which version of Visual Studio are you building with (if any)?

Microsoft Visual Studio Community 2015 Version 14.0.25123.00 Update 2

  • Which version of .NET are you building with?

.NET 4.0

  • If the problem occurs when installing your packages built with WiX, what is the version of Windows the package is running on?

Windows 7 SP 1

  • Describe the problem and the steps to reproduce it.

I have a custom burn application which is failing during install. To reproduce, run FramePro_x64_setup1_2_3_0.exe and install the software. This will complete successfully. Then run FramePro_x64_setup1_2_4_0.exe. The second installation will fail part way through. My custom burn dll will throw an exception "Font '?' could not be found". This only seems to happen on Windows 7. After the exception is thrown the main installer stalls and never comes back. Cancelling the installation leaves the installation partially installed (its in the windows uninstall list, but not installed). The only way around this is to manually uninstall the old version, and then re-install the new version.

If I uninstall the first installation manually the second installation installs without any problems.

I believe that the font exception happens because my custom dll can't access the .NET system.drawing.dll. It just happens that creating a font is one of the first things that my dll does.

When I originally moved to Wix version WiX v3.10.2 I had exactly the same exception trying to run the exe at all. The installer exe simply failed to start. After some internet searching it seemed to be related to the new security changes, specifically this change: wixtoolset/wix3#351. Updating to v3.10.3.2924 fixed the problem of the exe not starting at all, but then had the problem described above.

As far as I can work out the dll which throws the exception is my custom burn dll for the original installation. It appears that when the new installer runs the old installer to uninstall it, the old installer exe fails to start, in exactly the same way as the original problem I had with WiX v3.10.2 I.

If you want to try my installers they can be downloaded from here:
www.puredevsoftware.com/FramePro_x64_1_2_3_and_1_2_4_installers.zip

If you want to create your own application to reproduce the problem create a burn exe with a custom dll, which creates a font using system.drawing.dll. Install that, which will succeed. Then increase the version number in the burn Bundle.wxs and try installing that. The second installation will fail when it tries to uninstall the first installation.

I've attached a zip containing the two log files. They are both from the same install of FramePro_x64_setup_1_2_4_0. The larger log shows the main installer. I believe the smaller log shows the old installer running when it tries to uninstall. The log terminates because my custom burn dll throws the font exception as soon as it starts. I've also included my bundle.wxs

FramePro_log_and_wxs.zip

The machine I'm installing on is a clean Win7 SP1 install, installed on a VirtualBox VM and updated with (KB3020369) and (KB3125574).

  • Describe the behavior you expected and how it differed from the actual behavior.

I expect the update installation to succeed and not to throw an exception.

Please let me know if there is anything else that you need.

Many thanks,

Stewart.

@rseanhall
Member

Looks like embedded bundles aren't using a clean room process.

@barnson
Member
barnson commented May 27, 2016

@rseanhall Embedded because they're related bundles?

@rseanhall
Member

Yes, the new bundle launches the old bundle as an embedded bundle to uninstall it.

@barnson
Member
barnson commented May 27, 2016

So it doesn't need to be clean-roomed but needs to skip the SDDD call. Shiny.

@robmen
Member
robmen commented May 28, 2016

Ugh. I missed this when we no longer clean roomed processes running from the package cache and instead just launched the clean room process.

@rseanhall I'm not going to be able get to this soon... can you take a look

@rseanhall
Member

Yes, I'll take a look tomorrow.

@barnson barnson added this to the v3.10.3 milestone Jun 7, 2016
@barnson barnson added bug burn labels Jun 7, 2016
@slynch8
slynch8 commented Jun 8, 2016 edited

Hi,

I’ve just tried the WiX v3.10.3.3007 Release and I’m still having the same problem. Did the fix make it in to this release?

The old install that it’s trying to uninstall was built with v3.10.3.2924 in case that makes a difference.

Thanks,

Stewart.

@slynch8
slynch8 commented Jun 8, 2016

I've just checked updating an install that was built with 10.3.3007 and it does seem to work. Will the fix that was made only apply to updating installs that were made 10.3.3007? For people who have installed my product with v3.10.3.2924, they are still going to be hit by the problem when they upgrade to the fixed version. Is there any way around this?

@rseanhall
Member

You should be able to manually uninstall the previous bundle by itself by running the previous bundle. The bug is when the newer bundle is running and automatically uninstalls the older bundle (and the BA uses GDI+)

@slynch8
slynch8 commented Jun 8, 2016

Yes, I've put a note on my site to say that they should uninstall the old version manually if they run into problems, but it's not ideal. Anyway, hopefully not that many people downloaded the broken version.

Thanks again for the fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment