Application Will Not Start

7.1 Application Will Not Start

Distinguish no process, exit after a message, and a blocked window. An unseen login/dialog is not necessarily a crash.

7.1.1 Shortcut and Actual Runtime

Identify CDPS/COC, inspect shortcut Target and Open File Location, and verify the official installation, not a download, backup, USB, or isolated EXE. Check Task Manager, taskbar, and window switching for existing processes or hidden dialogs rather than double-clicking repeatedly.

Allow current database/save/device work to finish. Before an unavoidable termination, notify the owner and record unsaved work; do not assume writes were undone. If desktop and Start shortcuts differ, maintenance should correct them, not copy a new EXE into the old root.

7.1.2 Dependencies and Matching Files

Check 64-bit Windows and official runtime/provider/device requirements separately. This read-only PowerShell command checks Framework installation, not drivers:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' | Select-Object Version, Release

Release 528040 or greater indicates Framework 4.8 or later 4.x. Use Microsoft/official installers for missing components, not registry edits. Preserve missing-assembly/architecture names and verify the whole matching program/AuxTools/layout/UI/updater set. Do not download random DLLs. Integrity/publisher failures require formal file repair, not renaming, Debug replacements, or bypasses.

7.1.3 Permissions, Space, and Locks

Check system/install/temp disk space and endpoint-protection events. Administrators should verify quarantined files and restore official packages without disabling protection globally. Identify which access failed: loading, configuration, business folder, or share. Grant minimum required rights, not permanent elevation. For an update/recovery-in-progress message, use 7.10; do not delete protective markers or terminate every process in the directory.

7.1.4 Crash, Hang, and Rendering Evidence

In Event Viewer > Windows Logs > Application, inspect the incident's Application Error, .NET Runtime, or Windows Error Reporting entries. Preserve app, module, exception code, time, and frequency; export selected events, not just the last line.

For hangs, record the last successful step, wait duration, and layout. Do not unplug production writers/network to manufacture evidence. For blank/incomplete windows, record scaling, monitors, GPU driver, and remote-session status; restore normal display and retry once, then refer persistent faults to maintenance rather than unknown rendering switches.

7.1.5 Acceptance After Repair

Start once through the verified entry, check product/version/login/project, and keep automatic output off. Open a known-good layout and inspect a fictitious record/photo. Back up settings before any targeted reset; clearing the entire root may remove policies, defaults, sync, or licensing. Verify normal exit/restart, retained data, and the original operation without new errors. A main window alone does not validate data or devices.