EjectUSB

[spicydog]

I suggest using a huge hammer called ProcessMonitor and creating a log of what does it do.

I did that and all I get is a ton of:

EjectUSB.exe 688 CloseFile T:\ SUCCESS
EjectUSB.exe 688 CreateFile T:\ SUCCESS
EjectUSB.exe 688 QueryBasicInformationFile T:\ SUCCESS
EjectUSB.exe 688 CloseFile T:\ SUCCESS
EjectUSB.exe 688 CreateFile T:\ SUCCESS
EjectUSB.exe 688 QueryBasicInformationFile T:\ SUCCESS
EjectUSB.exe 688 CloseFile T:\ SUCCESS
EjectUSB.exe 688 CreateFile T:\ SUCCESS
EjectUSB.exe 688 QueryBasicInformationFile T:\ SUCCESS
EjectUSB.exe 688 CloseFile T:\ SUCCESS
EjectUSB.exe 688 CreateFile T:\ SUCCESS
EjectUSB.exe 688 QueryBasicInformationFile T:\ SUCCESS
EjectUSB.exe 688 CloseFile T:\ SUCCESS
EjectUSB.exe 688 CreateFile T:\ SUCCESS

but still no ejection

S:\ T:\ U:\ (the 3 NTFS partitions on the WD Passport) = T:\ is the partition where EjectUSB is located

What should I look for?

Thanks

[m^(2)]

1. For errors near the end.
2. Follow the log and EjectUSB code simultaneously to figure out what whether it did everything it should.

[spicydog]

1. For errors near the end.
2. Follow the log and EjectUSB code simultaneously to figure out what whether it did everything it should.

"...For errors near the end." = Errors? Eventual errors would be actually designated as errors? Sorry for the stupid question How can I distinguish an error from the rest of the other activities?

"...to figure out what whether it did everything it should." = How do I know that it did what it should do? (Again a stupid question! )

As you obviously understood I use ProcessMonitor as often as the pope goes bungy-jumping

[m^(2)]

1. For errors near the end.
2. Follow the log and EjectUSB code simultaneously to figure out what whether it did everything it should.

"...For errors near the end." = Errors? Eventual errors would be actually designated as errors? Sorry for the stupid question How can I distinguish an error from the rest of the other activities?

There is a "Result" column. Things that have 'success' are OK, but you'll always see plenty of ones that don't and are fine too. Hard to tell what to look for.

"...to figure out what whether it did everything it should." = How do I know that it did what it should do? (Again a stupid question! )

As you obviously understood I use ProcessMonitor as often as the pope goes bungy-jumping

As to tracing what a program does, the first thing is to filter the log, 'cause the big picture is entirely lost in 5000 entries. Remove all things that seem unrelated. Like, I got 3 EjectUSB processes in a trace and the 1st only started the second. RegCloseKeys are abundant and probably not useful. The same with CloseFiles. As long as you can find such things, keep removing them. Then hopefully you'll be able to recognise the EjectUSB code in the noted system events. And you may see i.e. that some code was not executed or there was some error.

But honestly, it's uneasy task and I kinda rushed with this advice, maybe others will have some better suggestions....

[spicydog]

But honestly, it's uneasy task and I kinda rushed with this advice, maybe others will have some better suggestions....

Thanks mate,

Indeed an uneasy task! But if you get some inspiration later on, please do let me know

Maybe somebody (like Queue or guinness, who is apparently busy re-compiling a new edition of EjectUSB) would be so kind to shed some light over this issue and point me in the right direction to identify the culprit of this recently surfaced malfunction.

I would really appreciate that

[webfork]

I have kept EjectUSB on my WD Passport USB external hard drive for almost a year and it has always performed flawlessly... Unfortunately since a couple of weeks (without having modified any of the EjectUSB settings) to safely eject my USB HDD (from my XP Pro 32 SP3 laptop) I am forced to put my system on standby, as there is no other way to get it to eject the way that it used to.

I'm having a similar issue, although the machine I'm on has always had this behavior and I have to shut it down. If I put it on standby, it complains when the computer wakes back up. I don't think it will hurt to disconnect the drive when its not actively writing, but I'd rather play it safe.

I think it has to do with an AV program that I can't modify and I was going to submit this to the EjectUSB dev if he (or anyone else) takes up the project again.

[m^(2)]

I don't think it will hurt to disconnect the drive when its not actively writing, but I'd rather play it safe.

Depends on OS settings, I've lost some data this way. And it was a part of a college project just before the deadline...

[spicydog]

I'm having a similar issue, although the machine I'm on has always had this behavior and I have to shut it down. If I put it on standby, it complains when the computer wakes back up. I don't think it will hurt to disconnect the drive when its not actively writing, but I'd rather play it safe.

I think it has to do with an AV program that I can't modify and I was going to submit this to the EjectUSB dev if he (or anyone else) takes up the project again.

Fortunately in my case it never reached the (terribly irritating) point of having to shut down (so I should consider myself lucky, I guess).

BTW, thanks for having up-rated the issue (not long ago we corresponded about that with ref. to the CodeSector/TeraCopy bug... CodeSector as of today is still totally AWOL).

Now let's hope that some-(EjectUSB)-body will give us a hand

What AV is allegedly causing that in your case? Same OS as mine? Same WD HDD as mine? If so, did you also check on the WD Passport forum?

[spicydog]

I am VERY HAPPY to confirm that I have finally identified the culprit

I am using MiniBin http://www.portablefreeware.com/launch.php?id=2081 and adjusting the CPU settings to 4 seconds does the trick!!!

I was really going nuts but at long last I solved the riddle... Now EjectUSB resumed its flawless performance

Hopefully this will help others who have been troubleshooting the same (extremely annoying) issue

Before dropping a line to Mike (e-sushi) I would be curious to know if anybody else experienced EjectUSB malfunctions on a system where MiniBin was actively running (with CPU value lower than 4 seconds).

[guinness]

(like Queue or guinness, who is apparently busy re-compiling a new edition of EjectUSB)

Sorry I missed that post. I've been busy with other projects lately and as SYSTEM mentioned Queue is at present updating EjectUSB. Because I would have to create a new icon and name as per Queue wishes, which is fair!

[spicydog]

Sorry I missed that post.

No prob, I figured/read you were busy

Queue is at present updating EjectUSB.

Yeah, really looking forward to that ...Any ETA?

[guinness]

No idea! I don't even know where Queue is?

[SYSTEM]

I've been busy with other projects lately and as SYSTEM mentioned Queue is at present updating EjectUSB.

I think you may have misinterpreted his message.

[guinness]

Perhaps my choice of words was a little off, but I'm sure one day in the future a new version will be available.

Version 1.7 (unreleased) does have some changes to handling how closing programs is handled (per user requests) but wasn't yet ready for release.

[spicydog]

Perhaps my choice of words was a little off, but I'm sure one day in the future a new version will be available.

Version 1.7 (unreleased) does have some changes to handling how closing programs is handled (per user requests) but wasn't yet ready for release.

Yes, the section you quoted could indeed suggest an approaching release... Let's see

And -back to the failure to eject USB HDD topic- the "Launch folder windows in a separate process" option (in Win Explorer Folder Options) seems to be (if checked) another part of the problem... Any comment about that?