Debug Logs and Incident Collection
On this page
6.7 Debug Logs and Incident Collection
6.7.1 Record the Incident and Impact
Stop actions that may enlarge the impact. Record time, application/window, operation, and full message. Distinguish startup, login, connection, empty results, save, and output failures. For printing/writing, record task position, physical output, chip completion, and database changes. Isolate uncertain cards/batches rather than repeatedly retrying.
6.7.2 Log Locations and Build Differences
Project debug logging is enabled in Debug and disabled in Release. Missing debug folders in a formal release is not necessarily a fault. Do not replace official files with unauthorized Debug builds for diagnostics.
CDPS/COC logs in debugging deployments are under the runtime root's localized system-test directory and the component's full project name. AuxTools uses its corresponding component directory when enabled. Inspect actual delivered names rather than renaming directories for this English guide. The updater uses the current run's random directory beneath %TEMP%\CREVIAUpdate, including runner and related debug logs. It may execute from a temporary copy, not the main installation.
Installation logs, Windows events, database logs, and device diagnostics are separate. No Debug log is not grounds to bypass security checks.
- Locate the actual runtime through the shortcut, sort relevant component logs by modification time, and copy the failure interval without moving/truncating originals.
- For updates, inspect
%TEMP%\CREVIAUpdateand the current runner directory. Retain error/time even if a Release build has no debug log; do not remove files still used by installation. - For crashes/startup, run
eventvwr.msc, open Windows Logs > Application, and filter the incident interval for the product, .NET Runtime, Application Error, or Windows Error Reporting. - Preserve General/Details, module, exception code, time, and path. Save selected events as
.evtx; do not clear logs or export unrelated organizational applications wholesale. - Include About version, and relevant dxdiag display/system or database/device-driver information. Review redaction before approved delivery.
6.7.3 Minimal Reproduction Materials
| Material | Include |
|---|---|
| Product/environment | Application, full four-part version, Windows/architecture/scaling, relevant GPU/device drivers. |
| Steps | Starting window, exact actions, expected/actual results, first occurrence. |
| Scope/frequency | Consistent/intermittent, one/all users, one/all layouts, one/multiple stations. |
| Evidence | Full message, incident time, relevant logs/events. |
| Data/equipment | Database type, photo source, printer/writer model/protocol, redacted sample. |
| Recent changes | Update, migration, drivers, paths, schema/permissions, attempted remedies. |
Prefer an isolated fictitious sample, not a full personnel database. If redaction removes the problem, describe the difference and agree a controlled collection method. Keep successful and failed timestamps for intermittent issues. Write "cause unconfirmed" rather than guessing corruption or claiming unperformed retests.
Example report (fictitious, not an actual product defect): COC folder photos became blank after moving StaffCard to COC02 at 09:20 on 2026-10-15. Windows 11 x64, 125% scaling, illustrative COC 11.0.0.0. Open StaffCard.skdCard, select DEMO0001; name/number display but photo does not. Old photos used D:, new files are on E:. All folder photos in this layout are affected; the old station works; no printing/writing was attempted. The new station opens the image, but the layout still references D:. Attach redacted previews, source settings, and version only. Example resolution: fix a test-layout path, check three records and reopen, then publish the controlled correction. This version and outcome are illustrative, not claims of current release or completed repair.
Figure 6.7-1. Show a clearly fictitious English message, About version, and relevant Windows event with time/window/error labels. Preserve useful codes while redacting identifiers; do not fabricate a screenshot presented as a real defect.
6.7.4 Redaction and Secure Transfer
Review screenshots, logs, and archives for names, identity numbers, contacts, portraits, chip IDs, passwords, tokens, license contents, and machine fingerprints. Paths, SQL, and exception messages can also leak information. Preserve useful structure, same-length dummy identifiers, chronology, and error codes. Unredacted material requires business/security approval and controlled support access, not public links.
6.7.5 Submission and Retesting
Use the normal feedback or agreed support channel with a concise title, impact, steps, and attachment inventory. Agree delivery for large files instead of repeatedly sending whole directories. Keep the ticket and originals.
Apply approved remedies with backups/maintenance, record changes, reproduce the original conditions, and verify affected normal work. A vanished message is not proof of saved data, readable photos, or physical output. Obtain business approval before resuming batches/automatic tasks and retain the lesson in maintenance records.
Figure 6.7-2. Show a fictitious English support submission and retest checklist with time, version, steps, materials, and results. Do not invent a diagnostic-export button. Hide contacts, internal addresses, keys, and real attachments.
Deployment and Maintenance Handover
- Record official versions, installation/dependencies, roles, and successful environment/device checks.
- Inventory all data, layouts, external photos, reports, policies, sync entries, and user views.
- Maintain consistent independent/offsite backups and tested isolated recovery.
- Verify every workstation's target, release, permissions, and batch ownership.
- Establish upgrade shutdown, acceptance, failure handling, and approved rollback.
- Assign maintenance/support owners and safe incident/recovery procedures.