The short answer: USBSTOR registry entries survive reboots and logons, but on Windows 8 and later the Plug and Play cleanup task removes entries for devices not connected for about 30 days unless that task is disabled. setupapi.dev.log records first-connection timestamp and driver install but can be rotated or archived on busy systems. Windows Event Log captures connection and disconnection with timestamps but rolls over per retention size. Together these three artifacts produce a forensic record of USB device activity that often survives years on an unmaintained system.
The USBSTOR Registry Key
The Windows registry key HKLM/SYSTEM/CurrentControlSet/Enum/USBSTOR is the primary forensic artifact for USB device connection history. The key is populated by the USB driver stack when a USB mass-storage class device is first connected. Each connected device produces a subkey containing the vendor identifier, product identifier, revision identifier and device serial number. The serial number is the load-bearing field for forensic identification because it uniquely identifies the physical device even when the same model has been connected multiple times.
USBSTOR entries persist across reboots, user logons and most cleanup utilities. They are not removed when the device is unplugged. Standard Windows disk cleanup, browser cache clearing and user profile reset do not touch USBSTOR. The exception is the Plug and Play cleanup task on Windows 8 and later: during automatic maintenance it removes entries for devices that have not been connected for about 30 days, unless the task is disabled. On those systems a missing USBSTOR entry is not proof that a device was never connected, so check setupapi.dev.log and the event logs too. Outside that task, the entries survive Windows update installs and most operator-driven system maintenance. The artifact is one of the most durable forensic records on a Windows system.
The setupapi.dev.log File
The C:/Windows/INF/setupapi.dev.log file is a text log written by the Plug and Play subsystem when devices are connected and drivers are installed. The log records the first-connection timestamp for each device, the driver package selected, the driver install outcome and the device instance identifier. For USB mass-storage devices the log entry includes the USB vendor identifier and product identifier and enough device identification to correlate against the USBSTOR registry record.
The setupapi.dev.log file is the source of truth for first-connection timestamps. The USBSTOR registry records the fact of connection but does not record when the connection occurred. The setupapi.dev.log records the timestamp. Windows can rotate or archive the log on busy systems, so the oldest entries can be lost. For machines with heavy USB device variety (developer workstations, IT technician laptops) the log may only cover the last few months of activity. For machines with limited USB activity the log can preserve years of history.
Windows Event Log USB Activity
The Windows Event Log captures USB connection and disconnection activity across several log channels. The Microsoft-Windows-DriverFrameworks-UserMode/Operational log records device installation events with timestamps. The System log records driver install and configure events. The Security log captures user logon and logoff events that correlate against USB device connection timestamps. The Microsoft-Windows-Partition/Diagnostic log captures partition-level events including USB storage device mount.
Event log retention is configured per log channel with default size limits. The default size limit for Operational logs is in the range of 1 to 20 MB which on a typical system covers anywhere from a few weeks to a few months of activity. Investigators triaging a Windows machine for USB device activity should preserve the relevant event log channels immediately because rollover continues during the investigation timeline if the system stays running.
User Attribution for Connection Events
The forensic question of which user was logged in at the time of a specific USB device connection is answered by correlating the USB connection timestamp against the Security event log session events. Event ID 4624 records successful logon with the user account name, the logon type and the session identifier. Event ID 4634 records logoff. The session identifier connects logon and logoff events into a continuous session.
The correlation procedure: identify the USB connection timestamp from setupapi.dev.log or the Operational driver log. Find the most recent prior 4624 event before that timestamp and confirm there is no intervening 4634 closing that session. The user account from the 4624 event is the attributed user. For systems with fast user switching active or with multiple simultaneous sessions the correlation needs the session identifier from the 4624 event matched against the session identifier in the device event log entry.
Use Cases the Records Support
USB device connection records support several recurring forensic investigation use cases. Data exfiltration investigations need to identify whether a USB storage device was connected during the suspect window and which user account had the device. IP theft investigations need to correlate USB device serial numbers across multiple machines to establish whether the same device was used to copy from one system and paste to another. Departed employee investigations need to confirm whether the employee connected unauthorized USB devices in the weeks before separation. Workplace policy enforcement investigations need to identify whether prohibited device classes (personal storage, mobile devices, music players) were connected. Where the goal is to prevent those connections rather than reconstruct them after the fact, see how to block USB drives on Windows.
For organizations operating Sherlock Forensics USB Write Blocker for endpoint USB device control the same Windows artifact set serves as the audit trail for the USB Blocker enforcement decisions. The Sherlock Forensics USB Write Blocker Pro integrates with the standard Windows USB enumeration path which means USB Blocker policy decisions and the underlying device events appear in the same artifact set. The Sherlock methodology pairs USB Blocker policy logs with the registry and log artifacts to produce a complete record of attempted and allowed device connections.
The Acquisition Discipline That Matters
For investigators arriving at a Windows machine where USB activity is in scope the acquisition discipline matters. First, preserve the registry hive (typically C:/Windows/System32/config/SYSTEM) and the setupapi.dev.log and the relevant event log channels before any analysis. Second, hash and document chain of custody. Third, parse the artifacts with tooling that handles the current Windows version (RegRipper plugins by Harlan Carvey for registry parsing, the standard Windows wevtutil utility for event log export, simple text parsing for setupapi.dev.log).
The artifacts are durable but the acquisition still matters because subsequent system activity can overwrite log entries through normal operation. The first hour of investigation is the cleanest snapshot the examiner will get of the relevant artifact set. Subsequent days of normal system operation can erode the event log retention and the setupapi.dev.log can rotate on size threshold under continued USB activity.
USB connection records are one of the most durable forensic artifact classes on Windows. They survive longer than browser history, longer than mail cache, longer than recent documents lists. For investigations where USB device activity is relevant the artifact set is the right starting point.
Frequently Asked Questions
Where does Windows store USB device connection records?
Windows stores USB device connection records across three primary artifacts. The registry key HKLM/SYSTEM/CurrentControlSet/Enum/USBSTOR carries the per-device vendor, product, revision and serial number. The C:/Windows/INF/setupapi.dev.log file records the first-connection timestamp and driver installation events. The Windows Event Log (DriverFrameworks-UserMode/Operational and System) records connection and disconnection events with timestamps.
Are USB device connection records ever deleted on Windows?
USBSTOR registry entries survive unplugging, reboots and user logons. On Windows 8 and later, the Plug and Play cleanup task removes entries for devices not connected for about 30 days unless that task is disabled, so a missing entry does not prove a device was never connected. setupapi.dev.log is appended to and can be rotated or archived on busy systems, so the oldest entries can be lost. Event log entries roll over per the per-log retention setting (typically size-bounded).
Can investigators tell which user was logged in when a USB device was connected?
Yes. Investigators correlate the USB connection timestamp from setupapi.dev.log or the Windows Event Log against the user session timeline from the Security event log (event ID 4624 for logon, 4634 for logoff). The correlation produces user attribution for the connection event. For Windows installations with multiple user sessions the correlation needs the session ID and the logon time bracketing the USB connection event.