Troubleshoot and refactor uninstall on Windows with Go 1.25+

[swiatekm]

We've upgraded to Go 1.25 in #10156, but ended up having to revert to Go 1.24's implementation of os.RemoveAll in the implementation of the uninstall command.

We need to diagnose what the root cause of the problem is and ideally make the uninstall process less sensitive to the implementation details of Go's file operations on Windows.

I'm going to update this issue with a more detailed account of the troubleshooting I've done later. As far as I can tell, the problem is that our approach to removing an executable which is actively being used is a trick involving NTFS Alternate Data Streams. This trick doesn't work with the new syscalls used by Go 1.25's os.RemoveAll implementation.

Why the ADS trick doesn't work anymore on Go 1.25

Go 1.25 introduced a new Windows implementation of os.RemoveAll in os/removeall_at.go, replacing the older path-based approach. For each file it encounters, it calls removefileat, which delegates to internal/syscall/windows.Deleteat.

Deleteat calls NtSetInformationFile with the flag combination at at_windows.go:297–303:

FILE_DISPOSITION_DELETE
| FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK   // ← new in Go 1.25
| FILE_DISPOSITION_POSIX_SEMANTICS
| FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE

The critical addition is FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK. This flag instructs the NT kernel to check whether the file has any active image sections — i.e., whether the file is a running executable — and return STATUS_ACCESS_DENIED if so.

If set, indicates the system SHOULD fail deleting the file if an image section exists. If not set and the FILE_DISPOSITION_POSIX_SEMANTICS flag is set; indicates the file can be deleted even if it has an image section. This flag was added to support backward compatibility with the existing behavior of the FileDispositionInformation (see section [2.4.11](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/12c3dd1c-14f6-4229-9d29-75fb2cb392f6)) operation.

Go 1.24's os.Remove calls DeleteFileW, which uses the old FileDispositionInformation API — a simple delete-on-close mark with no image-section check. Because FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK only exists in the newer FileDispositionInformationEx class, DeleteFileW is unaffected by it and can delete a running executable with an Alternate Data Stream.

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[swiatekm]

It looks like a simpler approach involving moving the executable out of directory and then scheduling it to be deleted on reboot works: ca96c66.

[swiatekm]

My proposal to fix this is to make use of the fact that while running executables can't be deleted on Windows, they can be moved. Instead of the fiddly ADS trick, we:

1. Rename the running executable outside the Agent directory.
2. Mark it to be deleted on reboot with MoveFileEx and MOVEFILE_DELAY_UNTIL_REBOOT.
3. The uninstall can now delete the agent directory normally.

Potential problems:

1. We're leaving a large executable behind after uninstall, which users may not be happy about. Especially relevant in the admittedly unlikely case of multiple installs and uninstalls without a reboot. We could try to clean these up on install, maybe?
2. Where do we move the executable? My current implementation uses the parent directory of the agent top path, which is guaranteed to have enough space, be on the same drive, and be writable. I can also see an argument for %temp% after verifying the drive is the same.

[ebeahan]

There was a past concern when during uninstall certain actions would trigger security software alerts that the agent process was doing something "suspicious": #2970

Unsure if the proposed approach would reintroduce similar alerts again, but I thought it worth calling out.

[swiatekm]

I think moving a file wouldn't trigger anything, but I'm not an expert on EDR. I guess moving to %temp% would be safer in this respect?