0x87D300C9 is the Intune Management Extension telling you it lost track of the process it launched. It is not a Windows Installer exit code, and it does not mean the install failed. It means IME was watching one process ID, that process went away, and the real work was still happening somewhere IME could not see. Wrapped EXE installers trigger it constantly. Native MSI installs almost never do.
Fast Verdict Matrix
| Behavior | Legacy EXE Behavior | MSI Behavior |
|---|---|---|
| Process IME watches | A stub or bootstrapper that extracts a payload, launches the real setup as a detached child, and exits. | msiexec.exe itself, which stays alive until the transaction finishes. |
| Result reported | Whatever the stub returned, often 0 or a hang, with the real outcome invisible to IME. | A standard Windows Installer code (0, 1603, 3010) that IME maps directly. |
| Behavior with no user session | Wrong or missing silent switch leaves a dialog waiting for a click nobody can make. | Fully non-interactive with /qn; no UI is ever created. |
| Detection afterwards | Install may finish after IME gave up, so the first detection run reports not installed. | Install is complete before msiexec exits, so detection runs against the finished state. |
The Rule of Thumb
- Intune can only judge the process it started. If the install command launches something that hands off to another process and exits, IME has nothing left to monitor and reports
0x87D300C9. - Check the machine before the package. The app is often already installed. Look at the target folder and uninstall key first; if they are present, the problem is process tracking and detection timing, not the payload.
The Fix: One Process That Owns the Install
The usual workaround is a PowerShell wrapper such as PSAppDeployToolkit that starts the vendor setup, waits on child processes, polls for completion, and returns a clean exit code. It works, but it is a script per installer that has to be re-tested whenever the vendor changes how its bootstrapper spawns children.
InstallMage removes the cause instead. It converts the source EXE into a native MSI, so the process Intune launches is msiexec.exe, the same process that performs the install and returns the result. There is no detached child to lose and no wrapper script to maintain. The comparison with script-based approaches is covered in the PSAppDeployToolkit vs InstallMage guide.
Deep Dive
What IME Actually Monitors
For a Win32 app, IME starts the install command line and waits on that process. When it exits, IME reads the exit code and applies the return code table. If the process launched is a bootstrapper, the sequence looks like this:
setup.exe (PID 4120) <- IME watches this
+-- extracts to %TEMP%
+-- starts msiexec /i payload.msi (PID 5532) <- detached
setup.exe exits (code 0) <- IME stops watching
msiexec.exe still running ...IME sees a clean exit, or a handle it can no longer follow, long before the real installer finishes. Depending on timing it records 0x87D300C9, or a false success followed by a detection failure.
Reading the Logs
IME writes to C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Open IntuneManagementExtension.log and search for the app ID. Compare three things: the time IME started the command, the time it recorded the exit or the monitoring loss, and the time the application files or uninstall key actually appeared. If the files appear minutes after IME gave up, you have confirmed a detached child rather than a bad payload. A failure that repeats with a real exit code belongs to a different problem, such as the one in the 1603 guide.
Reproducing It Under SYSTEM
Run the exact install command in the same context IME uses. A hang or a visible window here is the answer:
psexec -i -d -s cmd.exe
whoami :: nt authority\system
start /wait setup.exe /S :: your Intune install command
echo %errorlevel%If the prompt returns immediately while files are still being written, the setup detaches. If a dialog appears, the silent switch is wrong; the silent switch cheat sheet lists the correct flag per framework. Differences between this session and your interactive one are explained in the SYSTEM vs user context guide.
Frequently Asked Questions
What does Intune error 0x87D300C9 mean?
It means the Intune Management Extension lost track of the process it launched for the Win32 app install. The install may have succeeded on the device; IME simply could not confirm it because the launched process exited or detached before the real installer finished.
Does 0x87D300C9 mean the app failed to install?
Not necessarily. Check the target folder and the uninstall registry key on the device. If they exist, the install worked and the issue is process monitoring or detection timing. If they do not exist, reproduce the command under SYSTEM with PsExec to find a hang or a wrong silent switch.
How do I stop 0x87D300C9 without a PowerShell wrapper?
Make the install command a single process that owns the whole install. Converting the EXE to a native MSI with InstallMage does this, because IME then launches msiexec.exe directly and receives a standard exit code instead of losing a detached child.
0x87D300C9 is a tracking problem, not a payload problem. Confirm the install state on the device, find the process that detaches, and remove the hand-off so Intune watches the process that does the work.