Log Dejargonizer

Windows System Log · Event 7040

Event 7040: A service's start type was changed

Something changed whether a Windows service starts automatically, on demand, or not at all. Windows Update and installers do this routinely. So does anyone disabling security software, which is why this quiet informational event is one of the more useful ones in the System log.

Also written as Event ID 70407040 service disabled

What it means for you

On a personal computer

A background Windows component was set to start differently. Installing software, running Windows Update, or following a guide that told you to disable something all produce this. It is only interesting if it names something you did not change.

For an analyst

The event records what changed but not who changed it, which is its main limitation — pair it with Security Event 4697 or a 4624 in the same window to attribute it. Alert on transitions to 'disabled' for a named list of services rather than on the event generally: Windows Defender, the Windows Event Log service, Volume Shadow Copy, and any EDR agent. Note that a service can also be neutered by changing its binary path without touching the start type, which produces no 7040 at all.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
The start type of the Windows Defender Antivirus Service service was changed from auto start to disabled.

The fields that decide it

Everything else in the log line is context.

Service name
Which service changed. The display name is in the message; the short name is what you use in queries and in sc.exe.
Previous start type
What it was set to before.
New start type
What it is now.
  • disabledThe service cannot start at all until this is changed back. The value worth alerting on.
  • demand startManual — it will start only when something asks for it. Common and usually benign.
  • auto startStarts with Windows. Normal after an install.
  • delayed auto startStarts shortly after boot to reduce contention. A deliberate performance choice.
Time relative to other activity
Not a field, but decisive. A 7040 in the middle of an update window is maintenance; one at 3am on a machine with no scheduled work is not.
Which service
The service named matters more than the change itself.
  • WinDefend, Sense, WdNisSvcMicrosoft Defender components. Disabling these is a recognised precursor to running something else.
  • EventLogThe Windows Event Log service. Disabling it stops all further logging, including further 7040s.
  • VSS, swprvShadow copy services. Disabling them removes the ability to restore previous versions.
  • BITS, wuauservUpdate-related services. Routinely toggled by update management tooling.

Ordinary reasons this happens

Most of the time it is one of these.

  • Windows Update reconfiguring its own services during an update cycle.
  • Application installers enabling their service at install and disabling it at uninstall.
  • Management tooling applying a service configuration baseline across a fleet.
  • An administrator or a user following a troubleshooting or debloating guide.
  • Driver installs, which frequently register and reconfigure helper services.
  • Power management or optimisation utilities that set services to manual to speed up boot.

When it is not ordinary

Security software disabled before the real payload runs.

What gives it awayA transition to 'disabled' for Defender, an EDR agent, or the Windows Event Log service, particularly outside a maintenance window.

ATT&CK T1562.001

Backup and recovery capability removed ahead of encryption.

What gives it awayVolume Shadow Copy or the backup service set to disabled, usually within minutes of other destructive preparation.

ATT&CK T1490

A malicious service configured to survive reboots.

What gives it awayA newly installed service — recorded as Event 7045 — followed by a 7040 setting it to auto start.

ATT&CK T1543.003

What to do next

  1. Read which service it names before anything else. Most 7040s are irrelevant; a small named list is not.
  2. Establish whether the change was to 'disabled'. That direction is the one worth investigating; changes to manual or auto are usually maintenance.
  3. Look for an installer or update running in the same window — Events 7045, 7036 and the Application log's MsiInstaller entries all place the change in context.
  4. Because 7040 does not record who made the change, find the interactive session with Event 4624 or 4648 around the same minute and attribute it that way.
  5. If a security service was disabled, check whether it is still disabled now with 'sc qc <service>' rather than assuming the event reflects the current state.
  6. Check for Event 7045 shortly before — a new service followed by a start-type change is the ordinary shape of persistence being established.
  7. Set the affected service back and, if it will not stay set, treat the machine as compromised rather than misconfigured.

Queries to run

powershell Only the changes to disabled, which is where the signal lives. 
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7040} -MaxEvents 200 | Where-Object { $_.Message -match 'disabled' } | Select-Object TimeCreated, Message | Format-List
kql Scoped to the services whose disabling actually matters. Broad 7040 alerting drowns in installer noise. 
Event | where EventLog == 'System' and EventID == 7040 | extend Svc = extract(@'The start type of the (.+?) service was changed', 1, RenderedDescription) | where RenderedDescription has 'disabled' and Svc has_any ('Defender','Event Log','Volume Shadow','Firewall','Sense') | project TimeGenerated, Computer, Svc, RenderedDescription
splunk 
index=wineventlog EventCode=7040 "disabled" | rex "start type of the (?<service>.+?) service was changed" | stats count by service, host | sort -count
wevtutil Local read when there is no central logging. 
wevtutil qe System /q:"*[System[(EventID=7040)]]" /c:50 /rd:true /f:text

Common questions

Who changed the service? Event 7040 does not say.

It genuinely does not — the Service Control Manager records the change but not the caller. To attribute it, look at logons around the same minute in the Security log, or at Security Event 4697 if service auditing is enabled. In practice, correlating with the installer or update that was running is faster and answers the question most of the time.

Is Event 7040 normal?

Yes, and common. Every software install, uninstall and Windows Update cycle produces some. The event is informational precisely because the routine case dominates. What makes an instance interesting is the specific service named and the direction of the change.

Why does Event 7040 matter for security?

Because disabling a service is the simplest way to turn a defence off, and it leaves this record. Defender being set to disabled, the Windows Event Log service being disabled, or Volume Shadow Copy being turned off before files start changing are all recorded here. It is one of the few tampering indicators available on a machine with no security tooling installed.

A service keeps reverting to disabled after I re-enable it. Why?

Something is setting it back — Group Policy, a management agent, an optimisation utility, or malware. Check Group Policy first with gpresult, since a policy will silently reapply on every refresh. If no policy accounts for it and no management tool owns the setting, treat the machine as compromised: persistent re-disabling of a security service is not a configuration problem.

Read next

Mentioned by

Vendor documentation

Last reviewed 6 September 2026