Random huge amounts of --Event Viewer-- entries that cycle on and off, without a clear pattern, or confirmed reason.

trumpy81 said:

@Query01
I saw many of these entries in your EV log:

I assumed this referred to a RAID array that you had setup. My apologies if that is not the case.

Click to expand...

@trumpy81
No Raid, here's the docking-station (ds). Have a look at the attached zip file contents for additional insight. Reminder, the priority are the Event-Viewer entries that clearly indicate 'data loss' and 'unsaved data.'

Respectfully

Please run the V2 log collector and post a share link into this thread using one drive, drop box, or google drive.


Make sure that share links are available without sign in.

trumpy81 said:

Whenever a USB drive is disconnected/reconnected it can be assigned a different GUID etc. This essentially means that the shortcut no longer points to a valid location, which is why Windows offers to remove the dead shortcut.

Click to expand...

Sorry I just wanted to clarify this point. When you plug in a new USB device (and it's successfully mounted once), Windows creates persistent GUID's for the device and volume instances. If you re-insert this device, it won't do the "newly discovered device" dance.

There are Windows cleanup tools that refer to "ghost devices" or "ghost volumes". What they're referring to are hidden entries for all the removable devices and volumes your PC has seen in the past. And it still remembers them.

zbook said:

Please run the V2 log collector and post a share link into this thread using one drive, drop box, or google drive.

BSOD - Posting Instructions

BSOD - Posting Instructions This will show you how to help provide needed information about your system and dump files. It will not contain any personal or sensitive information about you or your data. To get better help with your Windows BSOD issue, please read these instructions and follow...

www.elevenforum.com

Make sure that share links are available without sign in.

Click to expand...

@zbook Scripts or code not locally written, and/or scripts that are too large to be reviewed in a reasonable time, won't be run on this machine.

garlin said:

Sorry I just wanted to clarify this point. When you plug in a new USB device (and it's successfully mounted once), Windows creates persistent GUID's for the device and volume instances. If you re-insert this device, it won't do the "newly discovered device" dance.

Click to expand...

@garlin I'm confused with your post, quoted above, compared to what trumpy81 previously posted. Whereby trumpy81 suggests --a dis/reconnect of a usb device "can be assigned a different GUID"; not that it 'will be'. garlin, I'm understanding the wording of your post to say/suggest, the GUID will be persistent (remain), across a dis/reconnect of a usb device. Is that not the exact opposite of trumpy81's post?

garlin said:

Sorry I just wanted to clarify this point. When you plug in a new USB device (and it's successfully mounted once), Windows creates persistent GUID's for the device and volume instances. If you re-insert this device, it won't do the "newly discovered device" dance.

Click to expand...

Yes, this is how things are supposed to work, but in the real world that is not always what happens.

Windows will run the newly discovered dance more than once on the same drive, often depending on how frequently the drive is connected/disconnected.

It can run every time the drive is plugged in or it may only run once every 100 connections or so, there is no set criteria for that to occur.

USB Hubs and ports also factor into the equation adding more uncertainty to the process and in some instances, they may be the instigator in the newly discovered process.

@Query01
Clearly I have read the EV log incorrectly since your drives do not appear to be a part of a RAID array. That still does not discount changing GUID's etc. and it does not explain the reference to RaidPorts.

There are a large number of these entries: Reset to device, \Device\RaidPort45, was issued. which arise from the UASPStor driver, which could be the main issue here.

Entries such as this: The IS operation at logical block address 0xebe5c6e for Disk 1 (PDO name: \Device\000001c0) was retried. give rise to drive connection issues, but it is difficult to say with any certainty what those issues are.

Are you able to reinstall the existing UASPStor driver?
Are there any updates for the UASPStor driver on the manufacturers website?
Are you able to install earlier versions of the UASPStor driver?

Is there any way you can separate the drives from the docking station and plug them in via another method?

I also wonder what the stability of your laptop is like without the docking station connected, are you able to test that without too much inconvenience?

If you do make any changes, save the current EV log/s and then clear them, so we can see what effects the changes have on the system.

@trumpy81 allow me to kind-of 'briefly' --hop over-- your post #23, then I'll return and annotate it.

Reviewing the most recent and substantial changes to address these Event-Viiewer (EV) entries, associated with these usb-connected hdd's resulting in both 'lost' and 'unsaved' data:

i) 20240109_161526 -- Begin restore to 20231204_111453, no installed drivers, or applications were affected/changed.

ii) 20240109_163424 -- Completed restore. The huge amount of EV entries have noticeably slowed, with some coming to an immediate halt; the sources: disk, ntfs and UASPStor, are among the few that have immediately stopped; system is once again stable.

iii) Within the last forty-eight hours of 'this' installment, I've spoken with and confirmed an available OEM BIOS update; said update has been installed. Post update, there was a brief, yet concerning hiccup, whereby A; was not recognized by the OS. Look at the last zip file contents to review A:. A: would not be seen even after power-cycling the docking-station (ds), or physically dis/reconnecting the usb-A port.

After a manual restart from the Win-button, A: returned. I have not yet asked the OEM\Tech-Supp what the updated BIOS was suppose to address or resolve. This incident with the A:, has been entered into my manual log, directly next to this thread --as something that needs to be monitored. I also checked the OEM site (manually) for updated chipset drivers; ****both BIOS and chipset are current.

trumpy81 said:

@Query01
Clearly I have read the EV log incorrectly since your drives do not appear to be a part of a RAID array. That still does not discount changing GUID's etc. and it does not explain the reference to RaidPorts.

Click to expand...

Also does not make sense to me and is 'another' reason why I think windows is doing this. Yet another thought is --why did 'System Restore' offer relief from the very 'EV\warning entries associated with the usb-connected hdd's suffering data-loss and unsaved data?

trumpy81 said:

There are a large number of these entries: Reset to device, \Device\RaidPort45, was issued. which arise from the UASPStor driver, which could be the main issue here.

Click to expand...

This would be the docking-stations

trumpy81 said:

Entries such as this: The IS operation at logical block address 0xebe5c6e for Disk 1 (PDO name: \Device\000001c0) was retried. give rise to drive connection issues, but it is difficult to say with any certainty what those issues are.

Click to expand...

For sure it is not a physical connection. I have run through (used) six of these same make\model docking-stations, that are all involved with the EV\warning entries I'm experiencing.

trumpy81 said:

Are you able to reinstall the existing UASPStor driver?
Are there any updates for the UASPStor driver on the manufacturers website?
Are you able to install earlier versions of the UASPStor driver?

Click to expand...

Nothing in 'Device Manager' labeled 'UASPStor.

trumpy81 said:

Is there any way you can separate the drives from the docking station and plug them in via another method?

Click to expand...

Negative, currently only 'this' laptop, the very reason I'm here seeking assistance.
NOTE: Another laptop is enroute, Win-10\Home, I'll have wiggle room to swap things and compare.

trumpy81 said:

I also wonder what the stability of your laptop is like without the docking station connected, are you able to test that without too much inconvenience?

Click to expand...

Cannot happen, this configuration is by design to be extremely mobile and modular. This is our version of a production machine for surveillance footage. As far as stability without using the ds, we need: a) Laptop = small foot-print with battery back-up, easily portable and operational while on the move. b) Surveillance grade hdd's, --internal SSD pricing as well as life-span is both cost prohibitive, and has a shorter SSD life-span as it relates to reads/writes.

Our application requires laptops and usb-connected surveillance hdd's

trumpy81 said:

If you do make any changes, save the current EV log/s and then clear them, so we can see what effects the changes have on the system.

Click to expand...

We absolutely will.

I have been discussing this for quite a bit with the OEM of the stations, it's turning into a finger-pointing game. The OEM for the ds claims everything works pristine in there lab then, point to my environment. Unable to contact Microsoft support and the Laptops' OEM also want's to point fingers. Some way I'll have to get concrete evidence, hopefully before the warranty expires.

Resprctfully

I believe UASPStor.dll is the name of the driver file and would be a part of the driver package, it is not the name of the device you would see in Device Manager.

Since this driver appears to be related to the Docking Station, I imagine it would have a name associated with that.

I was not trying to dismantle your setup, simply trying to isolate the main components and issues so that we can address those component/issues directly. At present there seems to be a number of factors conspiring to create the issues you see.

My suggestions were aimed at establishing whether or not the laptop itself played a role in the issues, including Windows.

I also suggested that you try connecting the hard drives to the laptop using a method other than the docking station, so that we could isolate the docking station as a part of the cause or not. This would only be a temporary situation for testing purposes, not a permanent one.

Your EV log also showed a number of failed saves related to the Swann software and my next suggestion would have been to disable that system for testing, temporarily.

Since you do not seem to be amiable to any of my suggestions, there is little else I can do to help, except to wish you the best of luck.

@trumpy81
Its not a matter of me being agreeable to your suggestions/recommenadations, this hardware setup, barring any specific brand name, is how we need the system to work. unfortunately for us, --this entire 'new' purchase of laptop, multiple ds and multiple hdd's don't seem to be playing well together.
This experience is a compound fracture to the fact, this box is replacing a previous laptop which the OEM is unable to repair, that OEM is now providing a replacement; yet to be received. This is just a mini-mess that must be resolved, Most of your suggested recommendations involving a process of elimination, drivers update(s) and/or driver rollback(s), posted to this thread, have already been thought of by yours truly; BIOS was the only update recently available.

**** NOTE: I will not abandon this thread regardless of how long it takes , in order to find --what is/are the contributing factor(s).
Moving forward, I ask the community to continue and watch or monitor this thread, I refuse to believe I'm the only one experiencing this. I will continue the research by doing the following then, providing date\timestamped feedback:

--Currently, since running 'System Restore' the EV\warning entries associated with these ds-connected\hdd's, have severely slowed; they usually cycle or circle back for another round. Let's wait and see how long this takes. BTW, the EV file I zipped and attached is from the Reset-PC date 20231028; completely in-tact; I could not see an interval-pattern.

--Next, the BIOS was updated, I'll continue monitoring this boxs'\usb-A\ds-connected\hdd's for additional EV\warning entries.

No other changes will be made to this machine for the next two (02) to three weeks; perhaps longer if the machine remains quiet in regards to thes usb connected drives. The replacement laptop for the initial machine is scheduled to arrive soon. I have two or three more of the same make\model ds that I can run side-by-side with this current box; then compare.

trumpy81 mentioned Swann, I'll provide more insight in the next annotated reply to post #28.

Thank you all for taking the time.

At some point I tried to fix every single warning and error found in Event Viewer. Most of them were permission related so not hard to fix. I almost got all of them and Windows seemed to work a bit more stable, especially while doing updates. This was on Windows Insider registered machines.

...anyways...you can, with 99.999% confidence, NEVER get rid of all the warnings. Does not hurt to fix most though, if you know what you are doing. If not, then better not touch anything, because you will most certainly break your whole OS into a state where restoring a backup or reinstalling is the only option back to a working system.

The computer had BSOD and /or unexpected shutdowns: 01/02/2024; 11/26/2023; 11/20/2023; 10/29/2023

Manual power offs (after hangs and freezes) can create some of the unexpected shutdowns and restarts.

If there are no new BSOD and /or unexpected shutdowns you do not have to troubleshoot them.

Images or share links displaying all test results (especially drive long generic, full error scan, and SMART) may be useful to review.

I'll sign off.

The other event problems you can workup as needed.

trumpy81 said:

I believe UASPStor.dll is the name of the driver file and would be a part of the driver package, it is not the name of the device you would see in Device Manager.

Click to expand...

Thank you, obviously I had no clue.

trumpy81 said:

Since this driver appears to be related to the Docking Station, I imagine it would have a name associated with that.

Click to expand...

I believe you are correct, it's a protocol.

trumpy81 said:

I was not trying to dismantle your setup, simply trying to isolate the main components and issues so that we can address those component/issues directly. At present there seems to be a number of factors conspiring to create the issues you see.

Click to expand...

I did not take it in a negative way, just wanted to confirm the reason the system is configured this way. If breaking it down did in-fact resolve the issues, the system would be useless for our application.

trumpy81 said:

My suggestions were aimed at establishing whether or not the laptop itself played a role in the issues, including Windows.

I also suggested that you try connecting the hard drives to the laptop using a method other than the docking station, so that we could isolate the docking station as a part of the cause or not. This would only be a temporary situation for testing purposes, not a permanent one.

Click to expand...

There are other methods, even other ds brands. For us, we moved away from non-ds methods; to messy (wires). This brand of ds is well known, cost effective and has a one-year warranty. Even temporarily replacing the current make\model ds, would either be cost prohibitive (currently), or have us seated with a wired mess and/or not reputable brand.

During the next thirty days, I'll have gathered research results and $$.xx to order the Startech docking-station; should there be a need.

trumpy81 said:

Your EV log also showed a number of failed saves related to the Swann software and my next suggestion would have been to disable that system for testing, temporarily.

Click to expand...

This is the sole purpose for this hardware configuration, is to write video footage 24/7 to one or more usb-connected hdd's. The EV logs that specifically name Swann, is an app-hang, not usually associated with EV log entries -source: disk, ntfs and or UASPStor. Additionally, with regard to Swann, Swann is configured to only write to one single hdd.

Example EV logs for lost or unsaved data is annotated in the attachement.

trumpy81 said:

Since you do not seem to be amiable to any of my suggestions, there is little else I can do to help, except to wish you the best of luck.

Click to expand...

I honestly was not expecting any one here to fix the box, more like I was thinking someone else has experienced this, or similar issues. The more I deal with this, the more unique it appears to be. I did see something similar posted back in 2015, but due to the date, I let it go..

Monitoring this thread ...

SlicEnDicE said:

At some point I tried to fix every single warning and error found in Event Viewer. Most of them were permission related so not hard to fix. I almost got all of them and Windows seemed to work a bit more stable, especially while doing updates. This was on Windows Insider registered machines.

...anyways...you can, with 99.999% confidence, NEVER get rid of all the warnings. Does not hurt to fix most though, if you know what you are doing. If not, then better not touch anything, because you will most certainly break your whole OS into a state where restoring a backup or reinstalling is the only option back to a working system.

Click to expand...

@SlicEnDicE we are speaking\discussing specific issues as it relates to usb-connected drives, your post appears to be 'generally speaking', I'm not understanding what specifically your post is offering to the usb-connected hdd discussion. Please further explain, I am interested.

Query01 said:

@SlicEnDicE we are speaking\discussing specific issues as it relates to usb-connected drives, your post appears to be 'generally speaking', I'm not understanding what specifically your post is offering to the usb-connected hdd discussion. Please further explain, I am interested.

Click to expand...

I was referring to the first post in this thread. Carry on.

All I can add to the USB discussion is that UASP (USB Attached SCSI) is a protocol that enables an external SSD to be used at almost the same speeds as when the drive was connected to a SATA port.

I have to catch up more on the thread to add value to it...

SlicEnDicE said:

All I can add to the USB discussion is that UASP (USB Attached SCSI) is a protocol that enables an external SSD to be used at almost the same speeds as when the drive was connected to a SATA port.

Click to expand...

Only SSD?

Query01 said:

Only SSD?

Click to expand...

Works for other storage medium too...but biggest diff is seen on fast flashdrives and SSDs

Anyways...USB is not a very good/reliable method for 24/7 surveilance. Have you considered doing this over the network instead? Gbit bandwidth is more than enough for multiple video streams...

SlicEnDicE said:

Anyways...USB is not a very good/reliable method for 24/7 surveilance. Have you considered doing this over the network instead? Gbit bandwidth is more than enough for multiple video streams...

Click to expand...

I did think about using the Lan, but there are issues there as well: a) already using the lan for sixteen ipc's via external WiFi antennas; building to building. As you know WiFi is uni-directional. Using a switch sends the cost up. We settled on usb-connected hdd's, until there's confirmation that usb is causing this.

Something else to note, if you are reading this entire thread and its attachments, these usb issues are not only with the hdd being written to from the video system. We also have a WD_RED connected via usb using the same hardware on another port. The WD_RED is basically storage for movies, music and general files; not constant 24/7 writing; It also has usb issues. By comparison, the hdd that is written to by the video system (A:), experiences most all the data loss; its hit and miss, not a constant occurrence. On the other hand, the storage hdd will completely get disconnected and most times will reconnect, albeit with a noticeable delay. Of course there will be data loss here as well, but only due to the user not saving the data to disk; unlike the video system.

Respectfully

Looking quickly at the event log, it seems the computer itself is having issues. Without the log collector report, I don't think there is much we can help with here. The logs contains everything needed to troubleshoot this issue. Without it we are beating a dead horse here.

SlicEnDicE said:

Looking quickly at the event log, it seems the computer itself is having issues. Without the log collector report, I don't think there is much we can help with here. The logs contains everything needed to troubleshoot this issue. Without it we are beating a dead horse here.

Click to expand...

That being the case, this will be figured-out without running any foreign\imported scripts on 'this' machine; which will never voluntarily happen. Manually running commands is fine, scripts = never.