High CPU usage, and No Drobo detected

My Drobo is no longer being recognized by Windows (using Windows 7). Drobo Dashboard does not recognize that any Drobo is attached. I have shutdown my computer, waited for the Drobo to go into Standby, and then power-cycled the Drobo before turning my PC back on. The result is always the same; my CPU usage spikes and the system becomes extremely slow, and no Drobo is detected. I have confirmed the CPU spike is due to the Drobo, because starting the computer up without the Drobo attached results in the system operating as normal. All the lights on my Drobo indicate that everything is fine, but when the Dashboard tries to connect to the Drobo, the CPU spikes, and seems to get stuck.

This began after I had restarted my PC, everything was normal, and my PC had tried to boot off of the Drobo (came up with an “Invalid Partition Table” error). I corrected the boot order in my Bios, and this is where the trouble began. The system started up normally, but now this issue. I’ve also installed the Dashboard on another system, plugged in the Drobo, and get the exact same behaviour. In Task Manager, the process running is “NT Kernel & System”.

I’ve opened a support ticket, but thought I would reiterate myself in here to see if anyone can help, as I’d like this sorted out sooner rather than later. Thanks in advance.

Is your Drobo connected to your Win7 PC via USB or FireWire 800? Have U tried to hard reset ur Drobo assuming you have a backup of your data.

It’s connected by USB. I have not yet tried a hard reset (and yes, I do have a backup of my important data). I’m hoping to find a solution so I can avoid that, as there are a few other things I don’t have a backup of, and would like to keep if I can.

how long do you leave it with the heavy CPU load and it trying to detect drobo?

how big are your formatted volumes on drobo?

sometimes (especially if your volumes are very large - 8 or 16TB - windows can take a VERY long time to detect drobo on boot

you dont say - what processor is in your machine?

with 16TB volume and on my intel atom powered media center - it could take 45 minutes to detect drobo after boot!

the rough rule fo thumb is tht it take 1 minutes per tb - so an 8TB volume would result in a 8 minute wait to be able to access drobo.

you also dont say if this has only recently started happening?

I’ve left it for quite a while, upwards of an hour, and it just continues.

I have 4x 500GB drives in it currently.

I’m using an Atom powered machine as well (dual core), but the thing is, I have rebooted plenty of times before, and this is the first time anything like this has happened. The Drobo volume is usually picked up immediately, I have never had to wait.


can you try leaving it overnight?

i’d also contact support in the mean time

Yeah, I’ve already started a support ticket. I’ll leave it for tonight (that poor little processor lol) and see what’s what in the morning. Thanks for the help.

no probs, keep us up to date!

Have you used Win 7 back up utility with your drobo?

When was the last time your ran chkdsk on your volume?

Chkdsk is a good start.
Beyond that, check if there’s an indexing or virus scanning happening on the volume. Some virus scanners can be set to scan removable devices when they’re plugged in.

But if it still isn’t mounting, then try a different USB port. It could be that either the removable storage driver didn’t load properly (drivers for USB devices load individually per-port).

I had used the Windows backup utility with the Drobo as the destination, and after reading in another forum that this may cause the system to incessantly scan the destination drive, I have changed the schedule and location of the backup, at least for now.

I have not run chkdsk on the Drobo volume since I got it up and running. I’m unable to at this point, since the volume simply will not mount at all.

There is no other process running that would cause this; Task Manager shows that the CPU spike is from the “NT Kernel & System” process. I have also tried a different USB port; I even tried plugging the Drobo into 2 other PC’s, all running Windows 7, and all resulting in the exact same behavior.

But here’s the interesting part; I started up one of my systems with a Ubuntu Live CD, plugged in the Drobo, and voila; I am able to mount the volume, and access all files, with no errors being output in the system logs. So it’s a Windows only issue, at least so far, but I’ve heard back from Support, and they have asked me to plug it in to my Windows system, and leave it for a few hours straight (I didn’t end up leaving it plugged in last night, the CPU usage was bothering me too much, and the system has other things to do as well). They believe the filesystem may have become corrupt, and Windows is simply trying to sort it out. So I’ll leave it going for a while, and se what happens.

At least I know all of my files are still there… at least currently.

Comforting to know your files are there… Let’s see what happens after it has a chance to sit for a while. It’s quite possible VSS is trying to reconcile itself.

If you are relying on windows to try and sort out a large file system, I would suggest plugging it into a slightly more powerful machine than your atom

Very good idea, I hadn’t actually thought of that.

I’ll plug it into my desktop. Thanks

I have to respectfully disagree. I’ve been using a Win7/Atom machine as a DroboShare replacement for my 4x1.5TB 2nd gen for well over a year without any problems.


I agree, the Atom powered systems are great. But if Windows is trying to verify the integrity of a very large file system, the added power from a slightly heftier cpu should reduce the amount of time it takes. Nothing against the Atom at all, just the sooner I get my Drobo back, the better :wink:

A bit of an update:

I plugged the Drobo into my more powerful desktop PC, and after about an hour, Windows did finally detect the drive properly. I ran chkdsk, but Windows came up with no errors. As soon as chkdsk was complete, and Windows tried to mount the volume again, the CPU spike occurred, and I was right back where I had started.

After waiting, I powered down the Drobo, and plugged it back into my other system (the Atom), and started everything up. The same thing occurred, except on this system it took about 2 hours for the volume to be recognized.

I ran chkdsk again from this system, and got the message:
“Correcting errors in the master file table’s (MFT) BITMAP attribute.
Windows has made corrections to the file system.”

But, once again, once chkdsk had finished, and Windows attempted to mount the volume, the CPU has spiked again, the PC is crawling along, and I assume I’ll be waiting another 2 hours before it’s usable again.

surely that the whole point - you dont have a problem? he does…

i had my drobopro connected to an atom based machine for a year without an issue - but if i needed to do some “heavy” work on it - i’d move it to my 4ghz i7 machine - since it was much much faster… and his main issue is smoethign is saturating his cpu usage - and we want to see if time will sort it out - so he could wait 4 days on his atom, or less than a day on a more powerful machine?[hr]

you still haven’t told us how large your volumes are (if you have i apologise but i just quickly scanned through the thread and couldn’t see it).

my atom win 7 machine used to take almost exactly 45 minutes to see my 16TB volumes (my core based machine was about 10 minutes)

it may be that the delay you see is “typical”,

but i think you are saying that it only relatively recently started… which would be odd - did you firmware update/change anything else recently?

My theory here is that there are (were) two problems in play.

  1. There were some errors in the MFT. These were corrected by the Chkdsk run.
  2. There is something Windows is processing/comparing/replicating/verifying/whatever and this is what’s delaying the mounting of the volume. I suspect this is related to VSS and Windows Backup, as the VSS snapshots are stored in the System Volume Information folder that Windows uses. The fact that Ubuntu mounts the volume OK seems to support the Windows-specific aspect.

So… my recommendation would be to:
Back up any important files
Mount the drive in Ubuntu
Delete the System Volume Information folder
Disable Windows Backup on your Windows machine
Then take the Drobo back to Windows

This should get rid of anything Windows Backup left behind (including any backups).
If the problem is Windows Backup putting stuff on the Drobo that progressively makes it slower and/or more confused, then the problem will return if/when you use Windows Backup with Drobo again, so wait a while to verify that this fixed things before trying Windows Backup again.

Sorry, I don’t think I mentioned it. I created a 16TB volume, for future expansion. There’s 4x 500GB drives in Drobo now, and I’m using a total of 1.1 TB.

And I don’t believe the delay is typical, as this only just started happening. For a few weeks the Drobo was fine and Windows had no problem with the volume. I had rebooted a number of times, and never had an issue. I have had the same Dashboard and Firmware version (the newest) since it came out of the box (I never had to upgrade either of them myself). And no other changes were made to the system, except for anything through Windows Update.

That sounds like it could be possible. I’ll give that a shot and see if it does anything. Thanks for the help, I’ll report back once I’ve had a chance to try it out.