How to tell if a USB drive was plugged into a PC

Windows keeps a plain text file at C:\Windows\INF\setupapi.dev.log recording every device it has installed, with the date and time of each and, for a USB drive, the vendor, product, revision and serial number. It is not hidden, it needs no software to read, and you can copy it off the machine and open it anywhere. PLUGGED reads it in your browser, decodes the storage entries and lists them oldest first, with nothing uploaded. What it tells you is when a device was first attached to that computer — which is usually the question — and not how many times it was used, because nothing in the file records that.

Why the usual answers are the wrong shape

Search this and you get four suggestions: open Device Manager, edit the registry, install USBDeview, or check System Report on a Mac. Two of them only show what is connected now, which is not the question. The other two need you to be sitting at the machine, logged in as an administrator, installing software on a computer whose history you are trying to establish — which is exactly what you should not be doing if the answer might ever matter to anybody else.

The log avoids all of that. It is a file. Copy it, hash it, read it somewhere else.

What a line in the log actually means

This is the part that decides whether anything you say afterwards is true.

Windows writes a section when it installs a device: the first time it sees that exact device, or when the driver changes. Plugging in a drive that is already installed writes nothing at all. So:

A tool that claimed otherwise would be inventing it. Several of the articles on page one imply a usage history that is simply not in the file.

Reading a USB storage entry

A section header for a memory stick looks like this:

>>>  [Device Install (Hardware initiated) -
     USBSTOR\Disk&Ven_SanDisk&Prod_Ultra&Rev_1.00\4C530001120523116&0]
>>>  Section start 2026/03/14 09:41:08.220

• Ven_SanDisk is the vendor string the drive reported.
• Prod_Ultra is the product. Real ones are padded with underscores to a fixed width, so Prod_Flash_Disk______ is "Flash Disk".
• Rev_1.00 is the firmware revision, which sometimes distinguishes two otherwise identical drives.
• 4C530001120523116 is the serial number, and &0 is an instance counter Windows adds.

The mistake that looks like a finding

Not every drive reports a serial number. Cheap ones frequently do not, and when the device offers nothing, Windows generates an identifier so it has something to key on. The long-standing test for telling them apart is the second character: a generated identifier has an & there.

Taking the second kind for a serial number and matching it against another machine's log produces a coincidence that reads exactly like a match. PLUGGED labels every row so the two cannot be confused, and counts how many of each it found before you start reading.

A failed install is still an attachment

A section ending FAILURE(0xe0000203) means Windows could not find a driver. It does not mean nothing was plugged in — the device was physically connected, was enumerated, and was identified well enough to be named in the log. Those rows are worth more attention than the successful ones, not less, and PLUGGED shows them by default for that reason.

What else is in there

• Boot sessions. Lines reading [Boot Session: ...] mark each start-up, which brackets everything between them.
• Phones and cameras. A device connected over MTP appears as SWD\WPDBUSENUM with a Windows GUID rather than a make and model. It tells you something was connected, and not what.
• The Windows version, in the header at the top, which tells you which build wrote the file.

Before you read it, and after

1. Copy it, do not open it in place. Reading a file on a live machine changes access times and can be the thing somebody later asks you about.
2. Hash the copy. CHECKSUM takes a SHA-256 in the browser. The first question asked of any examination is whether the copy examined is the copy received, and a hash taken at the start is the only convenient answer.
3. Record where it came from. CHAIN keeps who held what and when.
4. Take the backups too. The log is capped; when it fills, Windows renames it with a date and starts a new one. Those files sit in the same folder and are deleted routinely, so a device missing from the current log may be in one of them — which is why absence here is weak evidence.
5. Corroborate. The USBSTOR keys in the SYSTEM registry hive carry the same devices with their own timestamps, and the Windows event log records more besides. A conclusion resting on this one file is resting on one leg.

And the times are that machine's clock

Not UTC, not yours. As the computer had it set at the moment it wrote the line. If the clock was wrong, the log is wrong in the same direction and nothing in the file reveals it. PLUGGED shows every timestamp exactly as written and does not shift it into any other zone, because a time quietly moved by an hour is how a statement ends up wrong.

Alongside: WIRE reads a packet capture the same way, in the browser with nothing uploaded, and X-RAY tells you what a file really is when its extension is not to be trusted.