"Failed to Retrieve the User Profile Folder" Error

[MikeRowley]

I am getting "Failed to Retrieve the User Profile Folder Error" in a console application on Windows XP machines, not on all of them, just on some of them. Only when the updater is initiated from the AutomaticUpdater in the app, running wyUpdate.exe manually works properly.

The AutomaticUpdater is version 2.6.16.0

Any help you can provide would be appreciated.
Thanks
M

[Wyatt]

Is this an exception from the AutomaticUpdater or from wyUpdate? Can you give me the full exception (and stack trace, if available). Or is this an error event? If so please provide the ful details and what step it's happening under.

[MikeRowley]

The error is being kicked up by the AutomaticUpdaterBackend control's CheckingFailed event caused by the Initialize method in a console app which is launched by a Windows XP Service.

This only occurs when the console application is launched by my service, if I launch my EXE manually the updater works properly so it seems to be a user profile issue.

I have read previous posts about a wc folder under the %userprofile% directory, I have tried creating this folder with no luck, I even tried having the app create the folder based on its %userprofile% and it doesn't solve the problem for me.

Thanks
M

[Wyatt]

I'm going to look into this. But one question: is your service a "LocalService" service or a "LocalSystem" service?

[mikerowley]

My service is running under the LocalSystem Account.

Thanks
M

[mikerowley]

Any update on this one?

[Wyatt]

I'm not having luck reproducing this -- can you throw together a simple example service app that produces this behavior?

[mikerowley]

I can try to create a sample that does it, but it only happens on about 20-30% of my 120 machines that use the updater so odds are against it being easily reproducible. It seems absurd to me that there is no fallback plan if the "temp" directory cant be found, it manages to create an error message telling me what is happening (and I would assume telling you exactly where in the code it is failing) and if it fails the software cant be smart enough to create a temp directory to avoid failing completely, which ostensibly orphans a service with absolutely no ability to update itself, which is required to repair the problem even if there is a solution.

It just seems to me this should be a little more robust than this if it is an "automated" update solution.

As it seems to be a low percentage chance that I am going to be able to reproduce the problem, let alone reproduce it in a dev environment and even if I manage to get it reproduced on my side, even less chance of reproducing it on your side.

Seems like a waste of time to me when it is such a simple thing that is broken in your software.
I'm sorry if this seems like a rant, it is not intended as such but simply an accurate description of the reality of what you guys are building and the lack of robustness that seems to have crept into the code. Which will lead to me having to manually update at least 30-40 computers remotely because the updater cant create a temp directory to do its thing with. Seems like an oversight to me. And one that has been a problem in the past as I have seen this error in other forum posts.

Why can't the updater use a "standard" temp directory (c:\windows\temp) that everything else in windows uses? Or create its own? Or allow the user to specify its own if the previous options are not sufficient?

[Wyatt]

Why can't the updater use a "standard" temp directory (c:\windows\temp) that everything else in windows uses?

Because the files aren't guaranteed to be there after the service stops (thus requiring redownload, extracting, and patching everytime the files are deleted).

Or create its own?

Well, that's what we try to do. We're using a "system" folder (the "userprofile" folder) and we create our own directory inside this folder. There are only so many places we can put the files that we can guarantee that the system (or 3rd party tools) won't delete the files between multiple runs.

Seems like a waste of time to me when it is such a simple thing that is broken in your software.
I'm sorry if this seems like a rant, it is not intended as such but simply an accurate description of the reality of what you guys are building and the lack of robustness that seems to have crept into the code.

I fully agree. Bugs like this embarrass us to no end. We're trying to make something that doesn't have any "mission critical" bugs like this.




Is there any chance we can remotely debug this problem on one of the computers that experienced (or is experiencing) this bug? This way we can speed up the bug fixing process?

[mikerowley]

Excellent, that is definitely possible. if you email at m@bedsp.com, I will reply back later today or tomorrow AM with login details for a LogMeIn session on a machine as well as details about reproducing the app, where the files live etc.

Thank you very much for your assistance
M