Description
I found an issue when using AutoUpdater.NET with ZIP updates.
My application is a WPF application that supports drag & drop from Windows Explorer.
When using:
AutoUpdater.RunUpdateAsAdmin = true;
the update itself works correctly.
However, after the update completes and the application is restarted automatically, Windows Explorer can no longer drag files or folders into the application.
The mouse cursor shows the "not allowed" (🚫) icon.
If I close the application and start it manually again from Explorer, drag & drop immediately works again.
Investigation
After debugging this issue, I found that:
- Explorer.exe → Medium Integrity
- My application → Medium Integrity
- Drag & Drop works
- After AutoUpdater restart:
- Explorer.exe → Medium Integrity
- My application → High Integrity (Elevated = Yes)
- Drag & Drop is blocked by Windows UIPI
This is expected Windows behavior because a Medium Integrity process cannot send drag & drop data to a High Integrity process.
Root cause
DownloadUpdateDialog starts ZipExtractor.exe with:
processStartInfo.Verb = "runas";
ZipExtractor.exe then starts the updated application.
As a result, the updated application inherits the elevated token and continues running as Administrator.
This causes Windows Explorer drag & drop to stop working.
Expected behavior
The updater should run elevated only while replacing files.
After the update is complete, the updated application should be restarted using the original user token (Explorer token / unelevated) instead of inheriting the elevated token.
This is how many installers and updaters behave (Visual Studio Installer, Chrome Updater, etc.).
Suggested improvement
Instead of launching the updated application directly from the elevated process, restart it unelevated by using the Explorer user token (or another equivalent Windows technique).
This would:
- keep administrator privileges only for file replacement;
- restart the application as a normal user;
- preserve Windows Drag & Drop functionality;
- avoid requiring users to close and reopen the application manually.
Environment
AutoUpdater.NET.Official: v1.9.2
Windows 11 (also reproducible on Windows 10)
WPF application
ZIP update
RunUpdateAsAdmin = true
Description
I found an issue when using AutoUpdater.NET with ZIP updates.
My application is a WPF application that supports drag & drop from Windows Explorer.
When using:
AutoUpdater.RunUpdateAsAdmin = true;
the update itself works correctly.
However, after the update completes and the application is restarted automatically, Windows Explorer can no longer drag files or folders into the application.
The mouse cursor shows the "not allowed" (🚫) icon.
If I close the application and start it manually again from Explorer, drag & drop immediately works again.
Investigation
After debugging this issue, I found that:
This is expected Windows behavior because a Medium Integrity process cannot send drag & drop data to a High Integrity process.
Root cause
DownloadUpdateDialog starts ZipExtractor.exe with:
processStartInfo.Verb = "runas";
ZipExtractor.exe then starts the updated application.
As a result, the updated application inherits the elevated token and continues running as Administrator.
This causes Windows Explorer drag & drop to stop working.
Expected behavior
The updater should run elevated only while replacing files.
After the update is complete, the updated application should be restarted using the original user token (Explorer token / unelevated) instead of inheriting the elevated token.
This is how many installers and updaters behave (Visual Studio Installer, Chrome Updater, etc.).
Suggested improvement
Instead of launching the updated application directly from the elevated process, restart it unelevated by using the Explorer user token (or another equivalent Windows technique).
This would:
Environment
AutoUpdater.NET.Official: v1.9.2
Windows 11 (also reproducible on Windows 10)
WPF application
ZIP update
RunUpdateAsAdmin = true