I built a Windows NIC analysis/tuning project almost entirely in PowerShell and thought this might be interesting from the PowerShell side of things.
GitHub:
https://github.com/N3jjj/Universal-NIC-Analyzer-Tuner-Realtek-Tested
The original idea was to build a NIC tuner around one specific adapter/driver combination.
While working on it, I realized that hardcoding a fixed list of registry tweaks around one NIC and one driver branch is not very scalable.
Different NICs, driver versions and hardware revisions can expose different INF parameters, registry values and advanced adapter properties.
So I rebuilt the idea around:
Detection first, tuning second.
The project is now split into two PowerShell WinForms tools.
Universal NIC Analyzer v1.0
The Analyzer is completely read-only.
Instead of assuming a predefined list of settings, it tries to determine what actually exists for the installed adapter and driver.
It collects things such as:
- PCI hardware identity / VEN / DEV / REV
- subsystem information
- driver provider and version
- driver service and binary
- active INF section
- INF SHA-256
- driver SYS SHA-256
Get-NetAdapterAdvancedProperty settings
- hidden or profile-commented INF parameters
- registry-backed internal values
- RSS / RSC / LSO information
- Deep Analysis candidates
The Analyzer then exports a normalized JSON Portable Report.
That report deliberately contains no write instructions.
Universal NIC Tuner v1.0
The Tuner consumes the Portable Report, but does not blindly trust it.
Before allowing changes, it re-reads the live adapter and checks things such as:
VendorId
DeviceId
Revision
DriverModel
DriverVersion
INF SHA-256
Driver SYS SHA-256
If the live adapter or driver no longer matches the report, Apply stays locked.
I ended up implementing three separate write routes:
StandardAdvancedProperty
HiddenDriverRegistry
AdvancedRawRegistry
StandardAdvancedProperty is used for normal driver settings exposed through Windows advanced adapter properties.
HiddenDriverRegistry handles typed settings that exist in the active driver configuration but are not normally exposed.
AdvancedRawRegistry is an opt-in path for existing internal INF / registry values and Deep Analysis candidates.
For the registry-based routes, the existing live registry type is preserved.
Currently supported raw types are:
REG_SZ
REG_DWORD
REG_QWORD
DWORD and QWORD input can be entered as decimal or 0x hexadecimal values.
Transaction and safety model
A large part of the project ended up being about making writes recoverable instead of just making them possible.
Before Apply can run, the Tuner requires the relevant safety checks to pass:
Administrator privileges
exact live hardware/driver/hash match
verified backup
at least one proposed change
supported write route
valid proposed-value representation
no state drift
adapter restart route
final transaction integrity
The normal workflow is:
Settings
-> Preview Plan
-> Execution Model
-> Final Transaction
-> Apply
-> Restart adapter once
-> Read back changed values
-> Verify
A recovery journal is created before the first write.
If a write, adapter restart or post-write verification fails, the Tuner attempts to restore the original transaction state automatically.
The rollback itself is then verified as well.
There is also:
- manual rollback of the last successful Apply
- persistent verified backups
- standalone backup restore
- pre-restore safety snapshots
- differential restore instead of blindly rewriting the complete registry key
One edge case I ran into was preserving DWORD values such as:
0xFFFFFFFF
because PowerShell/.NET may expose that as signed -1, while the backup format needs to preserve the actual unsigned 32-bit representation.
Advanced / undocumented values
The Advanced mode intentionally does not assume that an undocumented driver value is safe just because it can be discovered and written.
For those values, the Tuner only knows things such as:
the value exists
its current value
its registry type
where it was discovered
whether it can be written
whether the new value was read back successfully
It does not invent:
semantic meaning
recommended value
safe range
performance benefit
That distinction became important while parsing driver INF data.
Advanced raw values are therefore clearly marked as detected-only and require an additional warning before Apply.
The Tuner also does not create missing raw registry values.
Verified backup and recovery
A Verified Backup represents the exact adapter-class registry state at the time it was created.
The backup includes things such as:
Portable Report fingerprint
hardware identity
driver model/version
INF SHA-256
driver SYS SHA-256
adapter class-key path
registry values
registry types
registry-state SHA-256
backup SHA-256
After a successful Apply, that old backup normally becomes stale because the live state has changed.
For another transaction, a new Verified Backup of the new state is required.
Standalone restore is independent of the normal transaction rollback.
Before restoring a backup, the Tuner creates a temporary safety copy of the current state.
Restore is differential, so only backed-up values that actually differ are rewritten.
Testing so far
v1.0 has currently been tested end-to-end on:
Realtek PCIe 2.5GbE Family Controller
RTL8125D / REV_0C
Realtek NetAdapterCx driver family
The following paths have been tested successfully:
StandardAdvancedProperty Apply / Verify / Rollback
HiddenDriverRegistry Apply / Verify / Rollback
AdvancedRawRegistry Apply / Verify / Rollback
- mixed-route multi-setting batches
- one adapter restart after the complete batch
- automatic rollback after intentionally injecting a failure after the first successful write
- Verified Backup creation and verification
- standalone Verified Backup restore
- pre-restore safety recovery
Intel, Broadcom, Marvell and other NIC vendors are currently untested.
The Analyzer is designed to discover other adapters, but I do not want to claim universal compatibility until the write / verify / rollback behavior has actually been tested on those driver families.
Why PowerShell?
I originally expected this to remain a relatively small script, but PowerShell ended up being surprisingly useful for tying together:
- CIM/WMI
NetAdapter cmdlets
- registry access
- INF parsing
- file hashing
- JSON serialization
- WinForms
- process elevation
- transaction logic
- recovery and rollback handling
At this point it has become as much a PowerShell project as a NIC tuning project.
I would be very interested in feedback on the PowerShell side in particular:
- structure / architecture
- WinForms approach
- registry handling
- transaction design
- error handling
- things that could be made more idiomatic
- compatibility issues on different Windows / PowerShell versions
And if anyone here has an Intel, Broadcom, Marvell or another Realtek NIC and wants to test the read-only Analyzer, that would also be useful.I built a PowerShell WinForms NIC Analyzer + Tuner with INF parsing, live validation, backup/verify/rollback and raw registry support