When the IT helpdesk is an AI

← All of

A real Windows troubleshooting case, walked through step by step with an AI assistant — a concrete look at what "AI as the first (and second, and third) line of technical support" actually means today.

There's one way to really see what an AI assistant can do in IT: not describe it in the abstract, but tell a real case, with every dead end, every course correction, and every moment where the first diagnosis turned out to be wrong. What follows is a real support session — spread over several days — in which someone with a badly broken Windows 11 PC fixed it by working in tandem with an AI assistant, never once calling a human technician.

The problem

It starts with a symptom that looks narrow: a couple of apps (Notepad, a third-party app) stop opening. You click the icon and nothing happens. You try to uninstall them, the process hangs for minutes, and it ends with a generic error. The PC was Italian, so the message read:

Notepad cannot be uninstalled. Operation failed. Try again later. Error code: 0x80073cf8.

Around it, symptoms that looked unrelated: a system process (svchost — the State Repository service) pinned at 25% CPU, and a Microsoft Store that could no longer download updates.

The assistant's first job wasn't to run a command — it was to read the whole clinical picture at once: to see that symptoms that looked distinct (apps not starting, a stuck uninstall, an empty Settings page, abnormal CPU) were probably all expressions of a single upstream cause. Here, a system database — the State Repository, which tracks installed app packages — left corrupted after an abrupt Windows crash. That ability to correlate heterogeneous symptoms into one diagnostic hypothesis, instead of treating each as its own problem, is probably the most immediate thing an assistant adds over a symptom-by-symptom search.

Reading logs and events

A correct diagnosis needs proof, not just plausible guesses. A good part of the conversation went into guiding the user — step by step, with exact paths — through Windows Event Viewer, to look for technical confirmation of the hypothesis:

Open eventvwr.msc → Applications and Services Logs → Microsoft → Windows → AppXDeploymentServer → Operational (if it isn't enabled: right-click → View → "Show Analytic and Debug Logs").

Every event we gathered (a 404 with a specific HRESULT, a 327 listing the exact packages in a transaction, a 1000 with the crashing module's name and file version) was used to confirm or rule out the current hypothesis — not simply to "have more information." One detail proved decisive: version 0.0.0.0 of a system file (ControlCenter.dll) — an almost sure sign of a corrupted file — found by cross-referencing two different logs (the application log and Windows Error Reporting) that reported the same crash from complementary angles.

Another, even more technical example: the generic error code 0x800704C7 returned by the Windows repair setup was put next to the automatic analysis from SetupDiag (Microsoft's official diagnostic tool), whose XML output we read line by line to tell a real blocker from a routine cleanup step.

Working from the command line

Most of the hands-on work happened in PowerShell and the Command Prompt, almost always elevated. Command consistency was a priority: once the right syntax for an operation was settled, it was reused verbatim in later steps, to cut the risk of typos or syntax slips in an already delicate context.

A few representative commands from the session:

# Check for an AppX package across all users
Get-AppxPackage -AllUsers *ScreenSketch*

# Re-register system packages (the shell's XAML components)
Get-ChildItem "C:\Windows\SystemApps\MicrosoftWindows.Client.CBS_*\appxmanifest.xml" |
    ForEach-Object { Add-AppxPackage -Register $_.FullName -DisableDevelopmentMode }

# Take ownership of a protected folder, using the universal SID
# (to sidestep localization of the "Administrators" group name)
icacls "C:\ProgramData\Microsoft\Windows\AppRepository" /setowner "*S-1-5-32-544" /t /c
icacls "C:\ProgramData\Microsoft\Windows\AppRepository" /grant "*S-1-5-32-544:F" /t /c

# Targeted reinstall of App Installer (winget), then the Store
Add-AppxPackage -Path ".\Microsoft.DesktopAppInstaller_x64.msixbundle"
winget install --id 9NBLGGH4NNS1 -s msstore --accept-package-agreements --accept-source-agreements

One snag, typical of an Italian setup: takeown /d y returned an error, because that command's Yes/No prompt is localized — on an Italian system it expects S, not Y. It's exactly the kind of practical friction an assistant can clear quickly, precisely because it can "reason" about the cause (localization) instead of just repeating the same command.

Screen sharing through screenshots

With no real remote access to the PC, the whole diagnostic channel ran through screenshots: error dialogs, Event Viewer panes, raw PowerShell output. That asked the assistant to:

• read and pull precise information out of Italian-language interfaces (field names, codes, timestamps);
• cross-reference several screenshots sent in the same message to reconstruct a coherent timeline, spotting patterns that repeat (the same crash with the same offset, every 30–40 seconds);
• tell, immediately, the few genuinely relevant lines from dozens of harmless "Information" events (here, a recurring crash of CrossDeviceResumeApp hidden among routine Winlogon and Intel graphics-driver events).

When even the screenshot key (PrtScn) stopped working — because of the same underlying problem — the diagnosis naturally stretched to cover that symptom too: a reminder that in real troubleshooting, the problem you're fixing can partly overlap with the tool you're using to diagnose it.

Errors and course corrections

The path wasn't linear, and it's only right to tell it that way. Some attempts needed an explicit correction. At one point the user asked, in Italian, to re-check the whole thing:

Re-check that the database-reset procedure is correct. Walk me through it again, step by step, and also tell me how to restore things if, after that attempt, the PC won't boot anymore.

That request — reasonable and prudent — led to a review of the original procedure, adding safety steps that hadn't been planned the first time around (backing up the BitLocker key, creating a restore point, a detailed rollback path). A useful reminder: even a technically correct diagnosis gains from an explicit "what if this goes wrong?", and a good assistant should take that in by adding a safety margin, not just reaffirming the original plan.

In another step, an attempt to reinstall the Microsoft Store through winget returned a message that wasn't clearly an error ("package already installed, no upgrade available"), which meant separating a real failure from a false alarm before reaching for the --force flag as a next step only if needed — rather than acting blindly on an ambiguous message.

Cross-checking sources (official and not)

More than once, the assistant paused the improvising to verify by web search before proposing an important step: what an error code really means, whether a documented Microsoft bug existed (here, a public issue with the XAML components of the Windows 11 shell, with an official mitigation), or the correct way to reinstall winget manually with no Store.

One episode is worth noting. When the user asked point-blank "where are these official Microsoft instructions," the assistant had to admit an imprecision — the procedure was technically correct and drawn from Microsoft sources (the official microsoft/winget-cli repo on GitHub and a Microsoft Learn page), but no single page described that exact scenario. Communicating that distinction honestly, instead of passing an assembled line of reasoning off as a direct citation, is a form of reliability worth more than an answer that merely sounds authoritative.

Another case was about practical safety: searching the Store for "Snipping Tool," the first results were all third-party apps with names and icons close to the original — but not the official Microsoft app. Recognizing that kind of "noise" in store results — fairly common — and not letting the user install a clone, verifying instead the official product ID (9MZ95KL8MR0L) against independent sources (Wikidata, Microsoft docs), is an example of how cross-checking sources isn't only about technical correctness, but also about a basic form of security hygiene.

Other things worth noting

Layered diagnosis, not a black box

The case wasn't solved with a single intervention, but through a sequence of ever-deeper hypotheses: first the State Repository database, then the shell's XAML packages, then a version mismatch between system components (24H2 and 25H2 mixed together), and finally whole packages missing after the repair. Each layer needed different tools (resetting a database, re-registering packages, an in-place repair from ISO, manually reinstalling components), and the assistant repeatedly had to flag, honestly, when a proposed fix risked being just a temporary patch over a deeper problem — avoiding the "shell game" of chasing one symptom at a time without ever hitting the cause.

Explicit risk management before irreversible actions

Before any potentially destructive step (renaming a system database, launching a repair of the entire OS), the assistant introduced preventive backups, disk-space checks and — a detail that's often overlooked — retrieving the BitLocker recovery key in advance, indispensable for any work from the recovery environment on a disk with encryption turned on.

Attention to localization

Several stumbles (the Italian service name, the Yes/No prompt in takeown, the log names in Event Viewer) are typical of anyone working on a non-English system: good AI support has to "translate" on the fly between the technical documentation (almost always English) and what the user actually sees on screen.

Closing

What comes out of this case isn't "the AI that knows everything," but a repeatable way of working: form a hypothesis, look for the proof in the logs, verify it against outside sources when it matters, act with precise and repeatable commands, prepare for failure before acting, and correct course out loud when something doesn't add up. It's a workflow very close to that of a good human support technician — with the advantage of holding dozens of logs, commands and different sources together in one thread of reasoning, without strain.