Event log warning

I'm getting many warnings about event ID 0 in Event Viewer when I run rclone to sync with my Azure cloud.
The description for Event ID 0 from source E:\rclone\rclone.exe cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

Here is a screenshot of one of these events:

Example command that I use:
E:\rclone\rclone.exe sync documents: azureblob:documents -v --fast-list
where azureblob is of type "azureblob" and documents is just alias for local folder

I'm using:

rclone v1.45
os/arch: windows/amd64
go version: go1.11

Anyone else getting these?
How can I fix this?

hi and welcome to the forum,

  1. did the rclone sync the data correctly?
  2. you might want to use a log file using --log-file rclone.log
  3. you might want to get debug info in that log using -vv instead of -v
  4. inside event viewer, where exactly did you get this event message?
  5. it is too soon to call this a bug yet.
  6. instead of documents: , try hard-coding the actual folder, c:\users\user\documents
  7. you might want to download rclone.exe again, it might be corrupted.

Can you check the timing of this a bit more specifically and see if it happens when the rclone process stops specifically?

Because what this intuitively looks like most to me is is just exiting with standard exitcode 0 to indicate a normal exit, and that is somehow being picked up in event viewer - but even viewer can't dig up any spesific information on this exit code and thus throws a warning.

Keep in mind that rclone was primarily developed on Linux, so I wouldn't be surprised if spesific support for this type of event-monitoring in Windows is lacking.

If this is the case then it would be a warning you could just ignore - or mute if that is possible.

I can't see this replicated in my own logs though (assuming it's under application).
Can you elaborate on how you installed rclone?
The thing that is throwing me off the most here is why eventviewer would be picking up this event in the first place... maybe that registers automatically if you run it via task-scheduler or as a service...

the event code 0 in the event log is not the same as the standard errorlevel/exitcode of 0 of an .exe that exited successfully

two different things.

Alright. Can you give a simple example of where an event code would typically originate from, so I have some way to relate it to the rclone system?

events can be created in so many ways.
any application including the operating system can generate event code 0 for all kinds of reason.
tho i am not an expert, i think event code 0 it is a catchall kind of thing of corrupted or missing files or registry entries.

take a look at this.

i want to wait until user reads my post with suggestions.
he should download the rclone.exe and try again.

  1. rclone syncs data correctly
  2. I'm using a log file, I've just ommited it from the example command
  3. I've downloaded the latest version now and get the same warnings
  4. the messages are in the Application log (Windows logs -> Application)
  5. changing the path / alias has no effect. Even a simple command such as "rclone lsd azureblob:" produces it

The timing is for each file uploaded, or for big files multiple events (for each chunk uploaded I think)

Have you tried it with Azure blob? It seems to be the culprit.
I have not really "installed" rclone so much as just extracted it into a folder.
Normally I do run a .bat file with rclone command from a scheduled task, but I get the same warning from doing it manually from Command Prompt.

Ok so now I've tried syncing a few files on my local FS to another folder on my FS and there is no events generated for this. But if I try an azureblob command (for example i tried rclone lsd azureblob:) I get a warning event in the log. I should also note that this happens on another computer as well (using a different azure blob repository).

  1. i use azureblob and have no such messages in the event log

  2. have you run rclone with the flag -vv instead of -v yet?
    in the rclone log, are there any warnings or errors?

  3. are there any errors or warnings in the rclone log that occurs at the same time as the message in the event log?

  4. you mentioned that you get the same event log entry on two computers.
    are you using the same exact config file on both computers?
    if so, in the config file, delete the entry for azure and re-create the entry and test again.

  5. create a .cmd batch file and add this command before the command for run rclone.exe.
    or from the command prompt, run this command and then run rclone.exe

set GODEBUG=http2client=0

I agree that we should take a look at debug output from rclone before we escalate this.
use either
--log-level DEBUG
to enable debug-level logging These get large real quick, so try to keep them limited to reproducing the problem as succinctly as possible. If even a simple command reproduces it then by all means use one of those. The less complicated we make the test-log the easier it is to narrow down the cause.

Hopefully the error in the event log is mirrored in some kind of error in rclone with more detail.

I have run the sync with -vv and it doesn't produce any useful info:

2019/10/19 18:55:17 DEBUG : rclone: Version "v1.49.5" starting with parameters ["E:\rclone\rclone.exe" "sync" "SampleFiles:" "azureblob:test" "-vv" "--fast-list" "--log-file" "E:\test\log.txt"]
2019/10/19 18:55:17 DEBUG : Using config file from "C:\Users\Peter\.config\rclone\rclone.conf"
2019/10/19 18:55:17 DEBUG : test1.txt: Sizes differ (src 22969005 vs dst 22969002)
2019/10/19 18:55:17 INFO : Azure container test: Waiting for checks to finish
***snipped log of other test files that were unchanged
2019/10/19 18:55:17 INFO : Azure container test: Waiting for transfers to finish
2019/10/19 18:55:27 DEBUG : test1.txt: MD5 = 0d37ac7eb6b849dee1d76acfedd5c5f0 OK
2019/10/19 18:55:27 INFO : test1.txt: Copied (replaced existing)
2019/10/19 18:55:27 INFO : Waiting for deletions to finish
2019/10/19 18:55:27 INFO :
Transferred: 21.905M / 21.905 MBytes, 100%, 2.128 MBytes/s, ETA 0s
Errors: 0
Checks: 6 / 6, 100%
Transferred: 1 / 1, 100%
Elapsed time: 10.2s
2019/10/19 18:55:27 DEBUG : 11 go routines active
2019/10/19 18:55:27 DEBUG : rclone: Version "v1.49.5" finishing with parameters ["E:\rclone\rclone.exe" "sync" "SampleFiles:" "azureblob:test" "-vv" "--fast-list" "--log-file" "E:\test\log.txt"]

I've also tried putting set GODEBUG=http2client=0 on the first line of the .bat file that executes the snyc command and I haven't noticed any difference in output.

The second machine has a different config and also a different Azure account. Both using cold tier blob storage.
Recreating the entry for azure storage blob made no difference.

I've now noticed the warning log only shows up for operations that take more than 3 seconds.
Notice the "Slow >3s" keyword:

==> REQUEST/RESPONSE (Try=1/3.6730596s[SLOW >3s], OpTime=3.6730596s) -- RESPONSE SUCCESSFULLY RECEIVED

When I was testing with small files there was no events logged.
Also all subsequent lsd commands produced no event, since they finished faster than the first one, which took ~10 seconds and produced another [SLOW >3s] response in event log.

ok, this is a mystery and i do not have an answer.

what are operating systems on both computers?

at this point, i do what i call monkey-business.
just start changing things and see what happens.

we need to try to change whatever is in common between the two computers.
and that only thing seems to be both use cold tier.
perhaps try hot tier.

When we don't see any obvious errors in the logs it's probably time to call in the boss for a comment.
Otherwise we risk a long and arduous wild-goose-chase before we stumble upon the trigger...

@ncw any ideas on how we can proceed with troubleshooting on this?

Both are using Windows 10 Pro 64bit

I've unset all Audit policies and still the Event persists.

I'll probably go back to ignoring the events if noone else has this "problem".

I would be willing to try to replicate your issue on my Windows10 setup with as-close-to-your-config as possible, but I don't have any Azure access.

So unless you trust me blindly to not mess with your data that would require you set up a temporary authorization that you can revoke later + a safe isolated testing area. If you are willing to go through that trouble I am willing to test it for you. You decide :slight_smile: It would no doubt be helpful information in rooting out the problem though.

I suspect it's not really a big problem all-in-all as long as you can verify your files do arrive whole and safe. That said, I hate leaving problems half-solved...

i was going to suggest to ignore the event log message but i am very paranoid.

there might be a chance that the uploaded data is corrupted.
you might want to run rclone check on the uploaded files

That would be the minimum requirement IMO before you ignore the problem aye - if that's the route you want to go with this.

I've ran the check and all files match with 0 differences found

If you're willing to test it I can give you access to a test storage. I'll set it up tomorrow and PM you the details. In the meantime @ncw might also shine some of his wisdom on this thing :slight_smile:

It looks like these events are being caused by the Azureblob Go SDK for some reason.

They look useless to me so I've attempted to disable them here. Can you give this a go?

https://beta.rclone.org/branch/v1.49.5-236-gef8986bf-fix-azureblob-event-log-beta/ (uploaded in 15-30 mins)

1 Like

Can confirm that this beta version is not showing any event in the event log.
Thank you :slight_smile:

One thing I noticed though: with the non-beta version when I accidentally tried syncing to root of the test azure container I got an actual Error level event in the event viewer, the beta version on the other hand hides all these events (Error and Warning level events). So if there's a way to let only Error level events through, someone might find them useful.

Great! Thanks for testing.

The control for the SDK seems to be on or off!

These events would only work for azure blob storage so I think the events are better off here and if we really want windows events then it should tie into rclone's logging system so all rclone events of a certain severity could become windows logs!

I've merged this fix to master now which means it will be in the latest beta in 15-30 mins and released in v1.50