DTLknowsWhy — User Guide v2.1

2.1 — GUI Mode

DTLknowsWhy.exe [--target IP_OR_HOST] [--lang {fr,en}]

• Select one or more situations that describe the problem (e.g. "Machine invisible in network neighbourhood", "Cannot access a remote Windows share")
• Enter the IP or hostname of the target machine if a situation requires it (marked with a star)
• Select the language for the interface and reports
• Click Run diagnosis
• Watch the progress log on the left; findings appear in the results pane on the right when complete
• Click Open HTML report to view the full report in a browser

2.2 — Local Snapshot (CLI)

python agent.py --snapshot [--lang {fr,en}]

• System: hostname, username, admin status, Windows version and build, LmCompatibilityLevel, BitLocker status
• Network: profile name and category (Public/Private/Domain), IPv4, subnet mask, gateway, DNS servers, DHCP status, NetBIOS option and enabled flag
• Local tests: ping loopback (127.0.0.1), ping self (own IP), ping gateway
• Services: LanmanServer, LanmanWorkstation, FDResPub, fdPHost, lmhosts
• Expert diagnosis: findings from the rules engine are embedded in the snapshot JSON

Three files named HOSTNAME_snapshot_TIMESTAMP.json, HOSTNAME_report_TIMESTAMP.txt, and HOSTNAME_report_TIMESTAMP.html. Paths are printed to the console on completion.

2.3 — Remote Target (CLI)

python agent.py --target {IP|hostname} [--lang {fr,en}]

• Ping: basic ICMP reachability
• Hostname resolution: name lookup from the IP address
• TCP port probes: ports 80 (HTTP), 139 (NetBIOS), 443 (HTTPS), 445 (SMB)
• MAC address: from the local ARP table
• Target classification: automatic type assignment
• Remote agent snapshot: if DTLknowsWhy-Agent is running on the target, its full JSON snapshot is retrieved and a causal comparison is performed automatically

Same three files as a local snapshot. If a remote agent snapshot was retrieved, it is also saved as a separate JSON file and the causal comparison is embedded in the main report.

2.4 — Server Mode

python agent.py --listen

GET http://172.17.7.10:5050/snapshot?key=DTLSECRET&lang=en

Returns HTTP 200 with the full snapshot JSON body. Writes JSON, TXT, and HTML files locally on every request.

2.5 — Remote Agent

DTLknowsWhy-Agent.exe --listen

DTLknowsWhy-Agent.exe install
DTLknowsWhy-Agent.exe start

DTLknowsWhy-Agent.exe stop
DTLknowsWhy-Agent.exe remove

3.1 — JSON Snapshot

HOSTNAME_snapshot_YYYYMMDD_HHMMSS.json

• metadata — generation timestamp, role (local/remote), target hostname
• system — OS, admin status, LmCompatibilityLevel, BitLocker status
• network — IP config, profile, NetBIOS option and enabled flag
• tests — local ping results (boolean)
• services — Windows service statuses
• diagnosis — expert engine findings (embedded)
• remote_tests — present only when --target was used
• causal_comparison — present only when --target was used
• remote_agent_snapshot — present only if the remote agent responded

3.2 — Text Report

HOSTNAME_report_YYYYMMDD_HHMMSS.txt

• Title and generation timestamp
• Local machine: identity, system, network, Windows services, local tests
• Expert diagnosis findings (level, message, remediation)
• Remote target (when --target was used): identification, port tests, classification, interpretation
• Causal comparison findings (when a remote agent snapshot was retrieved)

DTLknowsWhy Technical Report
==================================================
Generated: 2026-06-07 09:34:42

==================================================
LOCAL MACHINE
==================================================

Identity
--------------------------------------------------
Hostname            : PREDATOR
Username            : didier
Administrator       : Yes

System
--------------------------------------------------
Operating System    : Windows 11 Pro 23H2
Build               : 22631

Network
--------------------------------------------------
Profile             : Private
IPv4 Address        : 172.17.7.10
Subnet Mask         : 255.255.255.0
Gateway             : 172.17.7.1
DNS Servers         : 172.17.7.1
DHCP                : No
NetBIOS             : Yes (via DHCP)

3.3 — HTML Report

HOSTNAME_report_YYYYMMDD_HHMMSS.html

• Header bar: title, timestamp, NetDTL logo
• Local machine: identity, system, network, Windows services (collapsible), local tests (collapsible)
• Expert diagnosis (findings with level badges and remediation)
• Remote agent snapshot (if retrieved): second machine's full data in a mirrored layout
• Causal comparison (findings with cause and remediation)

4.1 — Expert Diagnosis

# Analyse the latest snapshot automatically
python expert.py --lang en

# Analyse a specific snapshot
python expert.py PC-BEN-002_snapshot_20260607_093442.json --lang en

If no snapshot file is specified, expert.py automatically selects the most recently modified *_snapshot_*.json file in the current directory. The typical two-step CLI workflow is: run python agent.py --snapshot, then run python expert.py with no arguments.

• Administrator privileges
• Gateway reachability (local connectivity)
• Network profile (Public blocks SMB and network discovery)
• LanmanServer and LanmanWorkstation service status
• FDResPub status (SMB-001: machine invisible in network neighbourhood)
• LmCompatibilityLevel value (0 = security risk; 5 = may block Workgroup SMB)
• BitLocker status (active drives: warn before any system configuration change)
• Remote target classification and SMB port accessibility (if remote_tests is in the snapshot)
• Auth error guidance for probable_windows targets with TCP 445 open (error 86/1326)

4.2 — Comparative Analysis

python compare.py REF_snap.json TARGET_snap.json [--lang {fr,en}]

PC B cannot access network shares that PC A reaches without difficulty. Collect a snapshot on each machine, copy both JSON files to the same directory, and run compare.py. The output will flag whether the cause is a Public network profile, a stopped SMB service, a gateway connectivity problem, a security product difference, or a configuration parameter mismatch.

• Network profile and gateway reachability
• LanmanServer, LanmanWorkstation, FDResPub, fdPHost service status
• NetBIOS option and DNS servers
• IP topology (gateway and subnet mask)
• TCP 445 accessibility
• Security products (Bitdefender presence and fltmc filter stack)
• SMB client and server configuration parameters
• Accessible SMB shares
• Identity context (local account, domain, AzureAD Joined)

5.1 — SMB-001: Machine Invisible in Network Neighbourhood

Select SMB-001 in the GUI and run the diagnosis on the invisible machine, or run python agent.py --snapshot --lang en on it.

FDResPub (Function Discovery Resource Publication) is stopped. Network neighbourhood visibility is handled by FDResPub and fdPHost, which are completely separate from the SMB protocol. SMB can work perfectly while the machine is invisible in Explorer.

sc config fdrespub start= delayed-auto
net start fdrespub

The error "the list of servers for this workgroup is not currently available" (error 6118 from net view) is normal and expected since Windows 10 1709. The SMBv1 network browser service is disabled by default. Do not attempt to re-enable SMBv1. Use \\MACHINE_NAME or \\IP directly in Explorer.

5.2 — SMB-002: Access by IP Works, Access by Name Fails

ping -4 MACHINE_NAME
nslookup MACHINE_NAME
nbtstat -A IP_ADDRESS

• NetBIOS disabled on one or both machines
• DNS does not contain an entry for the machine
• LLMNR disabled by policy
• FDResPub stopped (the machine is not publishing its presence)

If ping by name works but name-based SMB access is still slow: the delay is usually caused by Windows enumerating all shares when you browse \\NAME rather than going directly to a specific share. Map shares directly at logon to avoid the enumeration delay:

net use Z: \\MACHINE_NAME\share /persistent:yes

Also check the Credential Manager for stale tokens that may cause repeated failed authentication attempts before the correct account is tried.

5.3 — SMB-003: Authentication Refused (Error 86 or 1326)

net use * /delete /y

Then open Control Panel → Credential Manager → Windows Credentials and delete all entries for the target machine (including any MicrosoftAccount:target=... entries). After a reinstall with a Microsoft account, Windows may cache an MSA token that takes priority over local or domain credentials.

net use \\MACHINE\IPC$ /user:DOMAIN\firstname.lastname

Use the domain name (e.g. SC\anne.honnyme), not the local machine name (MACHINE\Anne). After a reinstall in Workgroup mode the machine no longer resolves the domain context automatically.

If error 1326 persists with the correct account format, check whether LmCompatibilityLevel is absent from the registry (DTLknowsWhy will show null in the snapshot). A fresh Windows install with the key absent uses the system default (NTLMv2 only), which some older servers or Workgroup configurations may reject.

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
  -Name LmCompatibilityLevel -Value 1 -Type DWord
# Restart required

Value 1 enables LM+NTLM+NTLMv2 negotiation. If this resolves the issue, the target server does not accept NTLMv2 alone.

5.4 — TCP 445 Blocked: net view Error 53 by IP

Test-NetConnection IP_TARGET -Port 445

If TcpTestSucceeded: False, proceed to the checks below.

sc query lanmanserver

If not Running: sc start lanmanserver

Verify that the inbound rule for TCP port 445 exists and is enabled. An easy test: temporarily disable the Windows Firewall on the target and retry. If access is restored, the firewall is the cause. Re-enable the firewall and create the appropriate inbound rule.

If ping MACHINE_NAME resolves to an IPv6 link-local address (fe80::...), this does not confirm that SMB is accessible on IPv4. Always verify with ping -4 MACHINE_NAME to get the IPv4 address, then test Test-NetConnection IP -Port 445.

5.5 — Network Discovery Keeps Turning Itself Off

Get-NetFirewallRule | Where-Object {
    $_.DisplayGroup -like '*Network Discovery*' -or
    $_.DisplayGroup -like '*Découverte*'
} | Select-Object DisplayName, DisplayGroup, Enabled

If only Wi-Fi Direct rules appear and no "Network Discovery" group rules are listed, the rules have been deleted (not just disabled). This can happen after security hardening, a GPO, or a third-party security tool.

# English Windows
netsh advfirewall firewall set rule group="Network Discovery" new enable=Yes

# French Windows
netsh advfirewall firewall set rule group="Découverte du réseau" new enable=Yes

If the command reports "No rules match the specified criteria", the rules were fully deleted. Reset the firewall to defaults or import the rules from a healthy machine. If the rules reappear but the checkbox resets again after a few minutes, a third-party security tool (e.g. an EDR or antivirus) is re-applying a policy. Identify the tool and configure an exception.

Run gpresult /r. If "Domain type" shows "Windows NT 4" or "Standalone workstation" with no applied GPOs listed, the issue is not Group Policy — it is a local firewall or security tool.