Diagnose Slow, Frozen, or Unresponsive Muhasib Screens
Diagnose Slow, Frozen, or Unresponsive Muhasib Screens
Overview
This guide will help you distinguish active work from a failed/frozen operation and collect evidence without causing duplicate writes.
The operation completes, is proven failed, or is safely stopped with duplicate-prevention evidence.
Who can do this
You need access to Normal workflow access; system/log/performance diagnostics require administration authority.
Before you start
Record screen/action, start time, data/filter size, company, workstation, network/SQL status, background operations, CPU/memory/disk symptoms, and message.
Where to find it
Remain on the affected screen; use authorized Windows, SQL, network, notification, and log diagnostics.
Diagnose Slow, Frozen, or Unresponsive Muhasib Screens
Step 1: Stop repeated clicks and wait for observable progress within local
Stop repeated clicks and wait for observable progress within local policy.
Step 2: Check whether the window/process is responding and whether SQL/network/background activity
Check whether the window/process is responding and whether SQL/network/background activity continues.
Step 3: For reports, reduce scope only to diagnose, not to declare full success
Step 4: For writes, query inquiry/history from another safe session only if
For writes, query inquiry/history from another safe session only if authorized.
Step 5: Preserve logs/timestamps before ending the process
Step 6: Restart only after classifying the operation outcome
Check your work
Application responsiveness returns and the requested write/report result is verified at its full intended scope.
If something goes wrong
- A spinning UI can accompany active database work; do not kill it blindly.
- Never treat a smaller diagnostic report as proof the full report completed.
Related guides
- Recover from an Interrupted Save, Finalize, or Conversion
- Collect Safe Diagnostic Evidence for Support
- Understand Back Office Background Operations