Tag Archives: USB
Determine what application is preventing your USB drive from ejecting [Win 10]
Boy, I haven’t posted in a while; it has been very, VERY busy here. As penance, I will make up for that with a post that addresses a common problem that afflicts us all: How to determine what application is preventing your USB drive from properly ejecting.
You know the deal: You try to eject your USB drive properly (which you should; otherwise a voltage change or write operation could damage data or the drive), only to have Windows give you the following dreaded dialog:
Uh Oh
The problem is, this dialog tell you absolutely nothing, other than something is using your USB drive. What are you supposed to do about this? Randomly shut down applications until it ejects properly? Save everything and reboot? What if the problem is not an open app, but a background process? How can you actually find out what app is causing this conflict.
Turns out, it’s not too difficult.
The first thing you want to do is open the Event Viewer, which allows you to see everything that is happening in your system, including recent alerts and what caused them. If you search from the start menu, it’s the only result you’ll see.
Click on the that, and the main Event Viewer interface will appear.
Main Event Viewer Interface
There are a lot of options, and a lot you can do from here. In fact, Event Viewer is a very powerful tool that it doesn’t hurt to become familiar with. For our purposes however, we will need to expand the ‘Windows Logs’ menu on the left hand side, then choose the ‘System’ log underneath that as non-ejecting is a system event.
System Log in Event Viewer
You’ll notice the fourth column in the main window is ‘Event ID.’ We need to see events that have an Event ID of 225. If you examine this log immediately after your USB drive fails to eject, you’ll see what you need to see right at the top of the list. However in the image above we don’t have that, so we have to filter the results to only show us events classified as 225.
In the right hand panel of the window, you can see the option to ‘Filter Current Log’ as the fifth entry down. Select that, and the filter window appears:
Filter Current Log dialog
There’s a lot you can do here as well, however all you need to do to determine the offending app is enter ‘225’ in the box that currently says <All Event IDs> then click [OK]. Once you do that, you’ll see every 225, or non-eject, event.
All events tagged 225
The top one is the most recent one that happened, and highlighting it will, under the general tab in the lower window, tell you exactly which program or process prevented the USB drive from ejecting. In this case, if you look at the full path you can see it is the ‘adobe_licutil.exe’ process, there at the end. Once you know that, it’s a simple process of the well-known [Ctrl]+[Alt]+[Esc] to bring up the task manager and shut the task down from there.
Task Manager
However, If it is still difficult to determine the specific process from the task manager because of a naming inconsistency, which has happened here, event viewer was also kind enough to provide us the Process ID, or PID, in this case 12592. In this case, if you want to be extra-double-sure, you can use Microsoft’s Process Explorer, a separate download, to identify the process by its PID instead of name, and shut it down from there.
Here’s an example of my Process Explorer, although out of habit I closed the task before taking the screenshot! But you can see the PID column and from there you can definitively ID the offending process.
Process Explorer
Remember, having to go to the extreme of Process Explorer is rarely required, and simply identifying the process and shutting it down from Task Manager is usually all it takes.
Destroy your stuff with just a USB stick
Hey, now this sounds fun! Want a simple, effective, and inexpensive way to destroy your expensive stuff and all the data on it? Well do I have good news for you! Now, with just a simple USB stick you can blow up damn near any digital device with a front-facing USB port (meaning publicly accessible, it doesn’t actually matter which direction the thing is actually facing. An important distinction).
The USB Kill will charge itself from the USB’s power supply, then discharge itself back into the port, over and over again until the host device is broken. Of course they say don’t use it for malicious purposes, but come on…why else would we want one of these things? Oh right – ‘testing’ purposes.
To be fair, everyone knows USB ports are a haven for malicious attacks, they’re the mosquito-breeding stagnant pond of digital devices, a very easy way to infiltrate a system or exfiltrate (steal or lose) its data.
It’s a pretty nifty device, in and of itself, and another interesting point they make is that only Apple devices are protected against this type of attack out of the box. Everyone else, well, look out (also, it might not destroy the data, and if it doesn’t, then NSA-approved bulk erasers are for you!).
Bad USB!
First off, my apologies for the late post. I spent all day recording the lecture for the week I’ll be gone, and it turned out to be much more involved than I had anticipated. I think it ultimately came out all right, but it took about six and a half hours.
So we’ll see how it goes, in the meantime here’s a late post.
There was, earlier this year, the revelation that every single one of the billions of USB devices out there has a fatal flaw in its firmware, in which a malicious user or hacker could reprogram it to fool the machine into which it is plugged that it is some other type of device. In other words, it may be a thumb drive, but its firmware could be reprogrammed to fool a PC into thinking it’s a keyboard, which would then allow it to send keypresses to the host machine and a malicious user to then get the host to carry out malicious tasks. The flaw is known as BadUSB.
