Loading today’s stories
Build1 distinct publisher2 min readUpdated
A five-move walkthrough of a stopped SQL Server argues for evidence before action. The restart that clears the alert also rotates the log that would have explained the repeat.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Restarting is not a read-only act, and on the host in this case it removes the two artifacts that explain a repeat. SQL Server rotates its ERRORLOG on every restart [16], so a bounce pushes the outage window out of the current file and turns the instruction to read the entries immediately before the stop [15] into a search by LastWriteTime [16]. Event 7036 records every service state change [6], including the one the responder just caused, and the pattern the guide teaches is several stop/start pairs in quick succession as the signature of a crash-and-restart loop [7]. A responder's stop followed by a start has the same shape.
StartType is where the recurrence hides. It shares the first query with Status because operating system updates occasionally reset it away from Automatic [4]. A manual restart returns the service to Running and leaves that field exactly as the update left it, so the alert clears and returns at the next reboot with nothing unusual in the application log to point at [17]. The author's read of the SQL case is that Windows Update had quietly queued a second reboot behind the Ansible one, and that without Event 1074 the outage would have looked unexplained [13]. Put the two findings together and you have the failure the restart cannot reach: the update changes the start setting, then supplies the reboot that tests it [19].
The reason the rule is cheap to follow sits in the same case. All three SQL services came back Running and Automatic when the first query ran, so the alert was valid but there was nothing left to act on [5], and the monitoring poll interval is why it outlived the outage [3]. A restart on arrival would have taken a running service down and written that stop into the log everyone was about to read [6].
One number worth checking before it reaches a customer note: the transitions are logged at 10:20 AM IST and 10:27 AM IST [8], which is seven minutes, and the write-up calls it six [9][10]. Durations belong to TimeCreated, not to the prose wrapped around it. The published walkthrough also breaks off mid-command at the ERRORLOG step [20], so the case never shows which of the three application-log signatures the SQL instance actually carried [17], and that is the part that would have separated a crash from a host that took the process down with it.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The author concludes that Windows Update had quietly queued a second reboot on top of the Ansible reboot, and that without checking Event 1074 this would have looked like an unexplained outage.
The application log carries one of three signatures: an error or exception before the stop means a crash, a clean shutdown message means a planned stop, and nothing unusual means an external trigger such as a reboot killing the process.
The walkthrough presents the investigation of a stopped Windows service as the same five moves whether the service is SQL Server, IIS, a background agent or a custom app.
The article's first rule is not to restart first: restarting without knowing why the service stopped can hide a failing update, an exhausted host, or an automation script that will stop it again in the next cycle. It tells the reader to spend five minutes on evidence first.
The first question is whether the service is still stopped, because monitoring systems have polling intervals and the service may have recovered before the alert arrived; ground truth comes before any action.
The first check is a Get-Service query returning Name, Status and StartType. Status shows whether the service is down now; StartType matters because OS updates occasionally reset it from Automatic.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One self-reported walkthrough, mechanically checkable but uncorroborated
Every claim rests on a single dev.to post. The mechanics it describes (Event 7036 state changes, 1074 reboot initiators, SQL ERRORLOG rotation, StartType exposure to updates) are concrete and reproducible in principle, and the commands are given verbatim, which raises evidence quality above pure assertion. It is pulled back down by the absence of any second source, screenshots or exported log excerpts, an internal timestamp-versus-duration inconsistency, and a body that terminates mid-command so part of the method is unpublished.
One disclosed environment, no broader uptake signal
The only adoption-shaped fact is the author's own environment: a SQL Server 2016-era instance patched by Ansible where Windows Update chained a second reboot. There is no release, benchmark, deployment count, or evidence that other teams follow this five-step sequence, so measured uptake is limited to that single disclosure.
Mildly overstated universality and precision
The substance is modest and mostly matches its evidence: standard event IDs, standard PowerShell, one real incident. The overstatement is in framing rather than findings - 'always the same five moves' for any Windows service is asserted from a single SQL Server case, and the headline diagnostic detail (a 6-minute outage) is stated more precisely than the timestamps support. Partial publication also promises a maintenance-window practice it never delivers.
Practitioner credibility post, no product being sold
The post is a developer-community write-up that promotes no vendor, product, license or pricing outcome; the commands are all first-party Windows and PowerShell, and the only named third-party tools appear as the cause of the incident rather than as recommendations. The residual incentive is reputational - publishing a clean runbook builds author standing - which favours tidy narrative framing such as a round '6-minute outage' and a memorable five-step pattern.
Moderate on mechanics, low on the specific incident
Confidence is split. The described Windows behaviours and the triage ordering are the kind of claim a reader can verify directly on any Windows host, so they are likely sound. The incident narrative - durations, self-recovery, which reboot caused what - depends entirely on one uncorroborated account that contradicts itself on timing and is published incomplete, so the specifics deserve lower trust than the method.
build
SynkLoader: the Teams help-desk lure now ships with a reverse proxy attached1 distinct publisher
build
98ms repo maps: what moving symbol indexing out of Node actually buys an agent1 distinct publisher
build
The malware asks a question and reads its orders off the doormat: PowerShell in FTP banners1 distinct publisher
build
Three manual interventions in a month, and every guard was working as designed1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 23, 2026