Skip to content

Troubleshooting — Logging

What evidence the application leaves behind when something goes wrong, and how to get more. The short version: very little by default. The finding is R8-7.

What is recorded

Source What it contains Where
Developer exception page Every unhandled exception, with stack trace, shown in the browser to whoever hit it. It runs in every environment (R1-1). The user's screen only.
Windows Application event log Framework messages at Warning and above, including "An unhandled exception has occurred while executing the request" with the exception. The default host adds the Event Log provider on Windows, with a Warning minimum. Event Viewer → Windows Logs → Application.
ASP.NET Core Module stdout log Everything written to the console — startup errors, framework Information messages, and every SQL statement (below). Off by default; see Deployment.
Application ILogger calls 27 LogInformation progress messages, all in the warehouse send flow (BStock, BAsset). None record an error. Console only, so the stdout log.
SQL statements Both DbContexts get their own LoggerFactory.Create(b => b.AddConsole()). That factory ignores the Logging section of appsettings.json, so every executed command is written at Information. Console only.
UpdatedUser table One row per successful sign-in: user, IP, time. Nothing else writes to it, despite its generic columns. NKO_DB; also the login-history screen at /Admin/History.
Hangfire tables State and exception details of warehouse background jobs. The Hangfire database — see below.

What is not recorded

  • Caught exceptions. There are 948 catch (Exception …) blocks. They return null, false, -1 or an "Operation Failed!" message, and none of them logs. The exception is gone.
  • E-mail failures. Both SMTP paths have an empty catch (R1-6).
  • Quartz jobs. UpdateNextUserJob and ExportHistoryJob use in-memory storage. A failed run leaves nothing behind.
  • Who changed what. There is no audit trail of edits beyond the per-document approval fields (NextUserId, status, the refusal columns).

Capturing an error

Situation Do this
The site does not start (HTTP 500.30) Read the Application event log; if empty, switch on the stdout log. See Deployment.
A user sees a stack trace Ask for a screenshot or saved copy of the whole page. The same exception is also in the Application event log, with a timestamp.
A screen says "Operation Failed!" or silently does nothing Nothing was recorded. Reproduce on a development machine with a debugger attached, set to break when an exception is thrown (not only when unhandled) — the exception is raised before the catch swallows it.
You need the SQL a screen runs Temporarily switch on the stdout log, reproduce once, switch it off. Expect a large file: every query of every request is written.

Turn the stdout log off again

The module does not rotate the file, and with SQL logging on it grows on every request. The stack traces and SQL in it also contain employee data. Treat it as sensitive and delete it once read.

Hangfire

No Hangfire dashboard is mapped, so failed jobs are invisible in the application, and Hangfire retries failed jobs automatically. To see them, query the job store (the default schema is HangFire):

SELECT TOP 20 j.Id, j.StateName, j.CreatedAt, s.Reason, s.Data
FROM HangFire.Job j
LEFT JOIN HangFire.State s ON s.Id = j.StateId
ORDER BY j.CreatedAt DESC;

A StateName of Failed, or a job going back to Scheduled repeatedly, is a failing export. The exception is in State.Data.