Backup forum

Please note, these examples are from a Windows 7 machine. Later Windows versions may differ slightly but will be similar.

Open up the Computer Management snap-in, in Event Viewer drill down to Windows Logs and right-click Application.



Now select Filter Current Log...



Scroll down until you see IDriveService and select it, then click OK.

Now you should see all the events for IDriveService in isolation and it will probably be apparent that it started very quickly after you booted the computer.

If its starting before other delayed-start services, this would suggest that the time value you entered is too low. Have you tried the value I suggested in milliseconds?

Let me know how you get on.

DaveLab wrote:

I waited a full six minutes, and IDrive still hasn't appeared in the Event list. All the while the service shows as "Running" in Services. Something's wonky.

I don't think it'll auto-refresh...

Maybe it's working, but we just can't witness it working other than indirectly like this?

I'm sure there are some monitoring programs out there that will show you real-time status of services and processes, but if you want a no-frills one, this batch file will do it:

@echo off
Setlocal EnableDelayedExpansion

:Begin
cls
echo Monitoring IDriveService
echo.
tasklist | findstr -i "id_service.exe" >nul
if NOT "!errorlevel!" == "0" goto NotRunning
echo IDriveService is running
goto Timer
:NotRunning
echo IDriveService is stopped
:Timer
echo.
timeout 10
goto Begin

endlocal

Just save it in a .cmd file and run it.

id_bglaunch.exe and id_tray.exe are programs that are run at login.

They could be delayed by running something else in their place, which launches them after a certain time. This wouldn't help if the Drive error occurs after sleep, because those programs will already be running.

You can see them in the Start-up tab of the Task Manager (Windows 10), or by running msconfig from other versions of Windows.

If you were to disable id_bglaunch, you could add the following to a batch file in All Programs / Startup:

timeout 120
start /min "" "C:\Program Files (x86)\IDriveWindows\id_bglaunch.exe"

I should point out that these programs are not necessary to perform a backup, they are only running if there's a logged in session (or more than one). If you left your computer at a login prompt (or logged out), IDrive would continue to work.

Sorry, another thing that's changed on Windows 10!

You can place items here so they start for a particular user:
C:\Users\USERNAME\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Or in here to start for all users:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

You should create the batch files with a .cmd extension (command file).

To disable existing Start-up tasks, highlight them in the  Task Manager Start-up tab and click the Disable button at the bottom of the window.

Sorry about the bg/gb mix up, my fault!

So something else is triggering id_bglaunch - probably id_tray or even id_service.

I've installed IDrive on my Windows 10 VM now, so I'll do some experimenting and see what I can figure out.

Well...

I now have both start-up files disabled, and a .cmd file like this:

timeout 120
start /min "" "C:\Program Files (x86)\IDriveWindows\id_bglaunch.exe" min
start /min "" "C:\Program Files (x86)\IDriveWindows\id_tray.exe" min

In order to hide the operation from the screen, I created the file in a separate folder and put a shortcut to it in the C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup folder. This in itself is not a simple task, due to a possible bug in Windows 10. If you want to attempt it, this video I found explains the workaround better than I can in words:



Once you have the shortcut in place, you can change the properties to Run: Minimized

Okay, here is where I've landed...

After the IDrive support dude remoted in, my boot-up prompt changed from "can't backup to your G drive cuz it's unavailable" to "can't backup to your C drive cuz it's unavailable." What!

And then, as one might expect, the scheduled local backup (scheduled, you may recall, for much later in the day) began happening to the C drive for each day thereafter. It turns out that that was the last time I saw such a prompt on boot-up, though. So that issue (my original issue for this thread) was apparently fixed.

When I first got that C drive prompt and noticed that it was, indeed, now doing the local backup the the wrong drive, I discovered that the destination drive assignment in the IDrive program had changed to C. So I set it back to G, thinking I'd be good.

Nope. Despite that setting in the program, days two and three showed backups continuing to the C drive!

IDrive support, which has been great on following up to see how things were going, asked me how things were going (via email). I replied as described above. Prompt worked itself out, but now it's going to the wrong drive.

They replied asking me to set the destination to G (which I did, again, although it was already there following my previous reset) and then do a quick test backup of a single file. Kind of a pain, because that meant deselecting all my backup selections to do that, then reselecting them all afterward. Anyway, I did that, and it seems to have rectified the problem; after doing the single-file test, which went fine, I reselected all my desired files and the full scheduled backup went fine to the G drive, as desired.

Then I deleted everything because my cloud backup was back to full-force. Oh, well. The things I do for science.

Long story not-so-short: Looks like there's a fix for my original issue that doesn't require delayed starting of any IDrive stuff. But, unfortunately, it's all "under the hood" from my customer perspective. Moral of the story: IDrive will fix it for you. Eventually. :^)

Many thanks to SteveA for his selfless dedication to my issue and to this forum in general. You, sir, are one of the good guys. I appreciate you, as the kids say.