Electron-builder: High Windows defender CPU usage when accessing NSIS installer

Created on 24 Jan 2017  Â·  42Comments  Â·  Source: electron-userland/electron-builder

  • Version: Various

  • Target: NSIS (Windows 32-bit) - Windows 10


Today, I noticed that the NSIS installers I have have built (current and ones from a few months ago) with electron-builder are causing Windows defender to act up.

To reproduce:

  1. I right click on my installer

    • Windows explorer hangs, and adds "not responding" to the window title

    • Looking at the task manager shows high CPU usage from the Windows defender service

    • If I keep clicking around the frozen window, explorer.exe crashes and reloads

  2. If I wait, after about 60 seconds, the right click menu finally appears.
  3. I click "Properties" and the same delay happens, although for not as long.

All of my installers are signed. I have tried this on 3 separate Windows 10 machines, all with the same results.

I have no reason to believe this is an issue with electron-builder directly, but I thought it would be useful to log it anyway, and to find out if anyone else is experiencing this issue.

Windows defender version:

Antimalware Client Version: 4.10.14393.0
Engine Version: 1.1.13407.0
Antivirus definition: 1.235.1170.0
Antispyware definition: 1.235.1170.0
Network Inspection System Engine Version: 2.1.12706.0
Network Inspection System Definition Version: 116.72.0.0
nsis question windows

Most helpful comment

13.5.0 released.

"nsis": {
  "unicode": false,
}

to disable Unicode. Still enabled by default — wait for NSIS or MS developers answer.

All 42 comments

Have you tried to add an exception to your appdata folder?
This is probably happening because its scanning every file as it comes in.

@willyb321: My installer does not get run; I am simply right clicking on it.

F* MS. F MS Defender. After some of the latest win10 updates (yet another restart, f* MS) I experienced the same behaviour (of course, I use VM using Parallels).

Maybe you can report bug to MS support? Or just disable defender and use some normal antivirus (if you use Windows)?

Thanks for issue reporting — I disabled MS F* Dedender and can work :)

Experiencing the same issue with Microsoft Defender. Althought it seems to already be very well known.

If MS cannot handle LZMA stream correctly — it is MS bug. I think it is temporary MS Defender bug and will be fixed soon. In any case MS Defender is *.

If MS will not fix it and it will be important for you — ZIP can be used instead of LZMA (maybe it will help) as an option.

@develar How do we use ZIP instead of LZMA?

@mikecao Sorry for confusion — not yet implemented, but possible (price — 1.5-2x size). In any case you can test it — set compression option to store.

Ok thanks. I would gladly pay a size penalty for a better experience for the users. Even clicking the exe to run the installer freezes for 60 seconds with Windows Defender on.

@develar What is the ETA on trying to get ZIP implemented?

@mastergberry Did you tried "set compression option to store"?

store: ~358MB
normal: ~76MB
maximum: ~76MB

Store is working fine with Windows Defender. Normal and maximum are both going slow with Windows Defender.

Sorry forgot to tag @develar again

We definitely need some other form of compression that isn't going to have issues with Windows Defender (Microsoft and their lovely software). As you can see the file is almost 5x bigger for us which is a huge impact on downloads/cost

@mastergberry Do you confirm that it is a latest regression in the MS Defender or do you observe such behaviour previously? Do you distribute ia32 or only x64?

We did not use this software you provide until 2 weeks ago and have experienced this since we started using compression.

At the moment we have only been distributing x64 but we will need to most likely provide ia32 as well.

@develar forgot to tag again .-.

At the moment we have only been distributing x64 but we will need to most likely provide ia32 as well.

FYI: NSIS installer contain both archs, https://github.com/electron-userland/electron-builder/wiki/NSIS#32-bit--64-bit

@develar Setting the compression level to "store" does not fix the issue for me.

FYI: NSIS installer contain both archs, https://github.com/electron-userland/electron-builder/wiki/NSIS#32-bit--64-bit

I see a --x64 and --i32 flag but it doesn't state what the default behavior with nsis is. Does it already build for both by default?

@develar is there an ETA for this feature fix? Next Monday i am pushing out first version of this software publically to a lot of users and i would much prefer to ship an 80MB file vs a 350MB file.

@mastergberry As @bontibon said, and I confirm, "Setting the compression level to "store" does not fix the issue for me". So, compression: store does not help MS Defender to be not so slow.

I will investigate issue this weekends.

There are 2 solutions:

  1. Use zip instead of lzma for app package. Not confirmed that it will help.
  2. F* MS Defender and just use http://nsis.sourceforge.net/Inetc_plug-in to load app package during install. So, installer will be ~500KB and * MS Defender will be happy.

Ok thanks @develar plz feel free to tag me for any testing that you need.

@mastergberry and others Please answer to 2 questions:

  1. do you need to distribute for both arch (ia32 and x64)
  2. is solution "download actual app package in runtime" is ok for you.

@develar

  1. Yes we need to distribute for both arch's
  2. This is fine for me as long as the actual app package can be compressed still and is not being bitched about by Windows Defender.

This is how a lot of products work, the installer is just downloading the actual app package and then runs it.

@develar:

  1. No, just ia32
  2. No, the entire app must be included in the installer
  • zip package DEFLATE — MS Defender hangs.
  • zip package DEFLATE64 — MS Defender hangs.
  • lzma package COPY — MS Defender hangs.
  • package as part of installer using nsis compressor — MS Defender hangs.
  • no package at all (150KB!!!) — MS Defender hangs.
  • no package at all and not compression (250KB!!!) — MS Defender hangs.

MS Defender hangs for a little even for a simple nsis installer.

"hangs" — "open context menu for file"

So, issue is not major — user just click to install and it works (several seconds to open).
If user need to open context menu on installer — just remove this yet another * "software" from MS and install normal antivirus.

If issue is major for you — open issue to add ability to download app package in runtime (it is good in any case because in this case you will not bundle 2 packages for different archs — correct arch will be selected automatically and downloaded).

Any attempt to shut up MS Defender (e.g. encrypt app package to hide content) will lead to block by normal antivirus software. So, it is not a solution and will be not considered.

Latest (insider preview) MS Defender 4.10.14393.726 is broken as well.

FWIW, I just noticed that this happens on the written uninstaller too.

@develar I do not think this has to do with a broken version of Windows Defender. Because If I use a very old installer made with electron builder 2.0 I do not have this issue.

Only when using the latest versions of electron builder the installer is super slow. I can see that the file architecture is different inside the installer and is not compressed. But that would be fine for us if we only could find a way for the installer to look the same as in version 2 of electron builder.

@UI-Jakob electron-builder now uses NSIS 3.0 Unicode. And it is an issue in the MS Defender. Because other antiviruses work correctly (no surprise, yeach, MS Defender not an antivirus).

Web installer feature is implemeneted (#1207).

that would be fine for us if we only could find a way for the installer

I guess we can try to cheat MS Defender using custom build of NSIS makensis (reorder С-structure to break detection). I will experiment on weekends.

@develar Alright because if I just revert to before we updated electron builder from version 2. It still works. even with latest version of NSIS.

@UI-Jakob You are hero. MS Defender hangs due to Unicode. Option to disable Unicode (or even disable it by default) will be implemented on weekends. Reported as https://sourceforge.net/p/nsis/bugs/1175/ Please contact MS support to ask about it.

Disabled unicode support means that installer will not display correctly unicode symbols, e.g. Schöne geschichte über Grünwald.

13.5.0 released.

"nsis": {
  "unicode": false,
}

to disable Unicode. Still enabled by default — wait for NSIS or MS developers answer.

@develar You are a freaking genius! Your new version solves the problem for us :D
(We do not have an issue with the limitations since we only have an english installer)

Wow, cool. I am having this issue too. Thanks @develar and @UI-Jakob :)

Awesome thanks for finding the bug @develar @UI-Jakob.

NSIS developers confirmed that it is a bug in the MS Defender (no surprise). Unlikely that MS will fix this issue anytime soon (or at least answer/confirm), so, probably, in the 14 Unicode will be disabled by default if product name contains only ASCII symbols.

MS fixed the issue in the MS Defender definitions update.

@develar so we can re-enable the unicode flag assuming the user is on the latest definitions right?

@mastergberry Yes.

Was this page helpful?
0 / 5 - 0 ratings