Troubleshooting

The states you may see, and what each one means.

GURDN tries to make its states self-explanatory, so this page is mostly about what each one is telling you and what, if anything, you should do.

The states

Healthy

GURDN observed the thing it checks, and what it observed held.

Degraded

Some protection capabilities are unavailable. GURDN is still monitoring the connection state it can observe.

Unknown

GURDN could not obtain this from Windows. It is reported as not known, and it is never shown as healthy.

Not supported

The capability does not exist on this Windows configuration. A fact about the platform, not a failure.

Failed

An action was attempted and did not succeed. GURDN says what it did and what state the machine was left in.

Unknown is not a fault

Unknown means GURDN asked Windows and did not get an answer. It is reported rather than hidden, and it is never shown as healthy. Common reasons are a capability that needs the service while the service is not running, a reading taken during a network transition, or a value that this Windows configuration does not expose.

Not supported is a fact about the platform

Some capabilities do not exist on some Windows configurations. GURDN reports Not supported with the reason rather than failing or working around it. Managing ordinary Windows Firewall rules is one example: it needs an interface this build deliberately does not use, and a request for it is answered with that explanation.

Degraded

Some protection capabilities are unavailable while others still work. GURDN names which, and keeps monitoring the connection state it can observe. A degraded result is never rounded up to healthy.

Recovery required

If the privileged service fails three times within an hour, GURDN raises a recovery-required marker, writes one entry to the Windows Event Log, and stops applying changes until the marker clears. Windows will continue restarting the service on its own schedule.

This is intentional: a component failing repeatedly should not be making changes to a firewall. See recovery.

The machine no longer matches

If something GURDN applied was changed outside GURDN, it reports the mismatch rather than silently reapplying. If you made the change, nothing needs doing; the next observation cycle records the new state as the current one.

The audit record does not verify

GURDN names the first entry that fails to verify. Entries written before schema version 3 carry no chain digest and are skipped rather than reported as tampered, so an upgraded installation does not raise a false alarm.

Diagnostics

A diagnostic export collects the local information needed to understand a problem. It is written locally and sent nowhere automatically; where it goes afterwards is your decision. See privacy.