Define the failure clearly
Record what the user expected, what happened instead, the exact message, when it began, and whether the issue can be reproduced. Capture the Windows edition and version when they can change the relevant procedure.
Ask how many users, devices, and applications are affected. The boundary often identifies the next useful layer.
- One application on one device points toward that application, its local configuration, or a dependency.
- Several applications for one user points toward identity, permissions, or a user profile.
- Several devices at one location points toward shared network, server, policy, or security changes.
- A failure that follows a device across users points toward device configuration or hardware.
Use a safe diagnostic sequence
- Record the symptom, exact error, time, affected user, device, application, and business impact.
- Check recent changes such as application updates, Windows updates, drivers, policies, password changes, network changes, or profile changes.
- Compare the affected device with an authorized known-good device using the same application version and role.
- Check the relevant service, network path, device, or application logs for the same time window.
- Make one approved change at a time and repeat the original action.
- Confirm the expected workflow with the requester and document any remaining risk.
Preserve useful evidence
Use the application vendor or Microsoft-supported method to gather logs. Keep the time range narrow and include the error context rather than sending a full system export by default.
Remove passwords, tokens, patient details, user names, hostnames, and public IP addresses before sharing diagnostic material outside the authorized support channel.
When to stop and escalate
Stop before registry edits, database changes, broad policy changes, service restarts, or reinstallations when the impact is not understood. Escalate when data integrity, clinical workflow, shared access, or a production service may be affected.