Manually uninstall the Azure ATP sensor

Brass Contributor

Hi all,

Just looking for a bit of guidance on the following.


Deploying the Azure ATP sensor to all our domain controllers, we've had one installation fail.  Looking in Programs and Features it is listed as being installed, however there is no Azure ATP sensor service on the domain controller.  Azure ATP is reporting the sensor stopped communicating.  


When trying to uninstall the Azure ATP sensor from Programs and Features, the uninstallation doesn't even start and the error is "Object reference not set to an instance of an object".


When trying to uninstall via command line "Azure ATP Sensor Setup.exe /uninstall" the error is "Product is not installed". 


The program is registered in the Uninstall registry, so when trying to uninstall via "msiexec /x {guid}" - it says to verify the package exists.  


Trying to reinstall the Azure ATP Sensor says "Azure Advanced Threat Protection Sensor is already installed."


I believe if I can manually uninstall it (delete files and associated registry entries) and try to reinstall it again it should be fine.  The original installation was pushed out via SCCM, so I'm not sure what happened during the install (if the server rebooted in the middle or what).


Can someone shed some light on the reg settings etc I need to delete?  Or if there is a way I can "force" a reinstall?




14 Replies

Can you grab the deployment logs before you close the error window?


Also, you might be able to clean things  up with this tool:


It is known to sometimes help before for similar situations.


What  exact version of AATP sensor is it?

Thanks Eli!

Your suggestion did help and it got me going in the right path.


This ended up being relatively straight forward so here are the steps I took if anybody has this in the future.


1. On the domain controller where the ATP Sensor had failed, I searched the registry for "Azure Advanced" (without the quotes), and deleted all keys and subkeys where this was found.   I just made sure it was referencing the sensor.  There were several keys that needed to be deleted from HKCR and HKLM.   Just to be sure to be sure....make a backup of the registry before you delete the keys.


2. I deleted the folder C:\Program Files\Azure Advanced Threat Protection Sensor


3. Manually re-installing the sensor worked and it is reporting as expected in the portal.   


Note: I had to manually delete the old (failed) sensor entry from the portal.


Hopefully this will help someone else out.

Can you share the failing call stack from the deployment log?

I wonder if I can change the code to auto recover from this situation.

The call stack might help me do that.

Hi Eli,

I've actually had the same issue occur now on a separate domain controller.  It looks like when the ATP Sensor went to self update, it broke itself during the install process.  And again the same result - it reports as not responding in the portal.  On the Domain Controller, there is no ATP service listed in services.msc, and the sensor is unable to be uninstalled (because it doesn't exist) and it's unable to be reinstalled because it thinks it already is.


I have some more information this time.  It appears to have happened on August 29th (a while ago I know - I only just got around to doing a better look into it).  I can see the following events in the application log.


Event ID 1040 (MSI Installer)

Beginning a Windows Installer transaction: C:\ProgramData\Package Cache\{D3EE6325-F634-4C55-9AA8-A197DB7781A4}v2.0.0.0\Microsoft.Tri.Sensor.Deployment.Package.msi. Client Process Id: 5644.


Event ID 10000 (RestartManager)
Starting session 0 - ?2018?-?08?-?29T04:54:37.351639000Z.

Event ID 1026 (.NET Runtime)
Application: rundll32.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 00007FFE6D3034D2
Event ID 1000 (Application Error)
Faulting application name: rundll32.exe_MSIE9AD.tmp, version: 6.3.9600.17415, time stamp: 0x54504eb8
Faulting module name: MSIE9AD.tmp, version: 2.43.5215.24283, time stamp: 0x590746fd
Exception code: 0xc0000005
Fault offset: 0x00000000000034d2
Faulting process id: 0xbdc
Faulting application start time: 0x01d43f5463b51c8a
Faulting application path: C:\Windows\system32\rundll32.exe
Faulting module path: C:\Windows\Installer\MSIE9AD.tmp
Report Id: addfe5ab-ab47-11e8-810b-000d3ad01b38
Faulting package full name:
Faulting package-relative application ID:

Product: Azure Advanced Threat Protection Sensor -- Installation completed successfully.
Windows Installer installed the product. Product Name: Azure Advanced Threat Protection Sensor. Product Version: Product Language: 1033. Manufacturer: Microsoft Corporation. Installation success or error status: 0.
Ending a Windows Installer transaction: C:\ProgramData\Package Cache\{D3EE6325-F634-4C55-9AA8-A197DB7781A4}v2.0.0.0\Microsoft.Tri.Sensor.Deployment.Package.msi. Client Process Id: 5644.
Event ID 10001 (RestartManager)
Ending session 0 started ?2018?-?08?-?29T04:54:37.351639000Z.



 So it's at this point the installation has failed - but actually finishes with a success code.   It looks as though this is another instance that will need to be manually cleaned up and then reinstalled.


I'm not sure if it makes any difference - but in the ATP portal I can see the failed sensor as last reporting v2.43.5215.  On the DC under C:\Program Files\Azure Advanced Threat Protection - I can see v2.47.544.8863 and 2.48.5521.36675





I had a similar issue with another customer  back than, the new sensor will know how to handle this case better, but if you are still stuck with the old version, the only way to uninstall it,

is to copy the binary exe from another sensor, and  register the service manually so the uninstall can find it. (the new code should not fail if it does not find it).

sc create  AATPSensor binPath= "C:\Program Files\Azure Advanced Threat Protection Sensor\XXXXXX\Microsoft.Tri.Sensor.exe"


where XXXXXX is the exact number of the version we try to uninstall, for example: 2.39.5033.27241


Once you have that, you can try to uninstall again (don't need to actually run the service).


Let me know how it goes.

This fixed it up for me. Many thanks.

@Eli Ofek 

I ran into a similar issue today on a 2008 R2 DC (I know...).  It was listed in programs and features list that it wasn't installed, but the installer wouldn't let me run.  Found 2 entries in the registry with "Azure Advanced" that were related to this, removed them, and then the installer went through.  Experienced an issue with the installer not being able to find msvcr120_clr0400.dll as well.  I installed the .Net Framework 2013 redistributables and then had to re-install .Net 4.7 and finally it's all good. 

Also... any idea why the 2019 DC's are reporting an error that NetBIOS over 137 isn't working properly?  The 2008 R2's, 2012's, and 2016's are all "healthy" in the console, but I've noticed 3 different 2019 DC's (with Windows Firewall disabled) are reporting an error.



@Noel Fairclough 


Cleaning the registry key worked.


Thank you,

@Eli Ofek 

I have the same issue happen to me today.  Windows 2012r2.  I think the server restarted during the install.  However there is not a log folder that was created.


Can't uninstall (says not installed).  Trying to reinstall it says setup is already running.  I'll try removing the registry keys and try the install again.



@Ken Brown  "already running" means you have another deployment process running.

Maybe you did not close the uninstall attempt or not waited enough time for it to exit?

I would restart the machine to make sure it's clean from running deployments and try to install again to see what happens...

@Eli Ofek 


Hi Eli!  Thanks for the reply.  That was after a reboot and it still thought it was running.  There was no logs folder.  I ended up using the other persons advice and searched thru the registry, removed all the Azure Advanced references, deleted the folder and reinstalled.


We are using a silent installer option - which in hindsight since we are doing this manually right now, probably should have remove the silent/quiet option.  I have found that after running the install, it would take upwards of 10-15 minutes before the services were installed (on medium busy domain controllers).  We are also installing the Azure Password Protection service - and that prompts for the reboot - which I know needs to be done quickly (due to the password filter being installed) so I am guessing I wasn't patient enough.  I have since done 5 more domain controllers and waited (the 10 or so minutes) until the ATP/sensor services are installed before proceeding with install of the Azure Password service.


I would suggest that maybe the installer (or maybe it has one?) a "/force" switch and not depend upon the uninstaller feature of programs and features in the corner cases where the code is not installed (correctly) but was partially installed and was in the state my install was.


Thanks again for the quick reply!

@Ken Brown Any chance the original install was done from a different account compared to the one you are using for the manual install? if this is the case, there is a registry entry that will cause it to auto start after a reboot... which explains the "already running" message, and also why clearing the registry might have helped here.


As for the /force option, it's not technically possible when relying on MSI installation,

but we are planning something better that will replace the entire deployment infra and could allow this in the future. sadly, I don't expect it any time soon, would guess 7+ months in best case scenario, with the possibility of being postponed much later... 

This was very helpful thank you.

@Eli Ofek This worked for me. I had to run that command with the old version and then copy another folder in C:\Program Files\Azure Advanced Threat Protection Sensor (there were newer version folders in there) and rename the folder to the old version number then I was able to fully uninstall and reinstall the sensor.