gup.exe crashes on some ZIP files and HTTP hosts?

  • My apologies if this is already reported elsewhere, I haven’t found it.

    I’ve been working since yesterday on getting the Poor Man’s T-SQL Formatter plugin included in the new plugin admin area, and have some frustrating time-consuming issues.

    Background - standard process ( for including a plugin and testing the resulting JSON:

    • Installed NPP 7.6.1
    • Replaced the “Notepad++.exe” binary with the debug binary from XXX
    • Replaced the gup.exe file, although I think it was identical
    • Updated the JSON file with my plugin, including correctly calculated SHA-256
    • Placed my JSON file with the right name in the same place for it to be picked up
    • (same process and outcome in 32-bit and 64-bit versions)


    • My plugin appeared in the plugin list
    • The plugin admin process could remove my plugin
    • When the plugin admin process tried to install my plugin, Notepad++ never started up again (said “we’ll need to restart NPP”, did so, but never started up again), and when I started manually the plugin wasn’t installed.
    • Other plugins installed and uninstalled fine
    • When NPP failed to start up again, the following message appeared in windows event logs:

    Faulting application name: gup.exe, version:, time stamp: 0x5c0d4e5f
    Faulting module name: gup.exe, version:, time stamp: 0x5c0d4e5f
    Exception code: 0xc0000409
    Fault offset: 0x0003951b
    Faulting process id: 0x3928
    Faulting application start time: 0x01d4ab229eedde00
    Faulting application path: C:\Program Files (x86)\Notepad++\updater\gup.exe
    Faulting module path: C:\Program Files (x86)\Notepad++\updater\gup.exe
    Report Id: 4094c231-e01a-4913-917e-1dd596aa1cd8
    Faulting package full name:
    Faulting package-relative application ID:

    I first thought it might be something do do with my download location/server, so I mirrored the ZIP files to another HTTP server, without any changes in behavior.

    Then I thought it might be the ZIP file itself (don’t remember how I created them back in the day), so I recreated them in WinRAR (and updated the SHA256 values). That worked - now my plugin installed.

    Then I replaced the original ZIP files on the original server (same SHA256), and tried again… again, mysterious crashes.

    In the end, I’ve used the new ZIP files on the new location (well, I was planning on switching to GitHub releases anyway, so that’s the new hosting location…) - but I’m confused about how I could have had two different issues both affecting gup.exe in the same way…?

    For testing, the “Bad” binaries (ZIP files that cause crashes) are hosted (on a “good” server) at:

    The “Good” binaries are hosted on a “Bad” server, at:

    Finally, the good files are hosted on a good server in the final pull request (

    Please let me know if there’s anything else I can provide or test to help understand what weirdness is going on here.


  • @Tao-Klerks

    Regarding your “Bad” binaries hosted on a “good” server

    Gup.exe currently uses an unreliable ZIP component (see comment of this commit), it took some releases and intensive testing to achive the current state. It may be that your old ZIP files could not been unzipped by this component.

    Regarding your “Good” binaries hosted on a “Bad” server

    This problem is caused by GUP.exe, see this issue in the GUP issue tracker. I’ve even explicitely mentioned your plugin there. It would be nice if you would leave a note there, that your plugin is no longer affected by this bug because of its changed hosting location.

  • Thanks @dinkumoil - I’ve updated the existing issue and created new Issue #10 for the ZIP file problem. I guess we can consider this thread closed, except insofar as it might help future plugin developers reach the issues if/when appropriate (I, for one, did not know that the relevant GitHub project was

Log in to reply