1409063 - FF 56.0.1 x64 on W7x64: now creating events in "Microsoft-Windows-Known Folders/ Operational" event log, "Error 0x80070005 occurred while creating known folder" for all known folders, upon each FF startup.

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect, P1)

Description

[Paul]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171002220106

Steps to reproduce:

start FF


Actual results:

the mentioned event log has many warnings added to it re: CREATING known folder;

note this isn't the more typical "verifying" error.

note this started when the "forced update" to the x64 version occured w/ 56.0.1

Comment 1

[Kohei Yoshino [:kohei]]

Please troubleshoot with Safe Mode: https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode

Also, the abbreviation of Firefox is Fx, not FF.

Comment 2

[Abe - QA (:Abe_LV)]

Hi Paul,

I started Firefox 56.0.1 on Windows 7 x64 and checked if there is warning log in the Event Viewer, application section.  
I also checked the browser console for possible errors, but could not manage to get any.

Here is the screen capture: https://testing-1.tinytake.com/sf/MjA0MzcwMl82NDQxMzM4

If you still able to reproduce this, could you please provide more information on how to reproduce this?  
Please also attach about:support information. Thanks

My test environment is:
Name 	Firefox
Version 	56.0.1
Build ID 	20171002220106
Update Channel 	release
User Agent 	Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0

Comment 3

[Abe - QA (:Abe_LV)]

Comments received from the reporter (Paul)by email:

> as originally requested, I started Fx in Safe Mode - the log warnings
> did not appear.
> ran again in normal and I get a consistant 10 warnings in the KNOWN
> FOLDERS event
>log upon each startup of Fx

>must be either an add-on or something in the add-on foundations used
> by an add-on.

> my add-on's are:   noscript, httpseverywhere, downthemall,
> downthemallanticontainer, supportfreecontent, and inlinedisposition2.

I installed all those add-ons on Firefox 56.0.1 on Windows 7 x64, but still, could not see "Known folders" error in the event viewer.

Since the reporter does not reproduce it in safe mode, the error may be caused the addons. 
Based on this, I am putting this under the extension-compatibility component.

Comment 4

[Paul]

just to make sure we're clear, the specific event log is "Microsoft-Windows-Known Folders/ Operational"

you need to dig down in the event viewer: Application and Services Logs | Microsoft | Windows | Known Folders

Another bit of info: I run with UAC turned OFF. Perhaps with it turned on these accesses are virtualized 
and therefore do not "fail".  Either way the warning error is not fatal, just curious.

Comment 5

[Abe - QA (:Abe_LV)]

(In reply to Paul from comment #4)
> just to make sure we're clear, the specific event log is
> "Microsoft-Windows-Known Folders/ Operational"
> 
> you need to dig down in the event viewer: Application and Services Logs |
> Microsoft | Windows | Known Folders
> 
Thanks for explaining, I can see the warning under "Known Folders". But it is not related to add-ons. I am able to reproduce it without any external addons.  After every Firefox restart I can see warnings  like "Error 0x80070005 occurred while creating known folder {b4bfcc3a-db2c-424c-b029-7fe99a87c641}. I can reproduce this on beta and the latest nightly builds as well. 

So, I am going to reset the component to "untriaged" and will investigate this more and put in the appropriate component.

Comment 6

[Jim Mathies [:jimm]]

Looks like the error is associated with out content temp directory. Bob, can you take a look?

Comment 7

[Bob Owen (:bobowen)]

I see similar events on my win10 machine, but it doesn't seem to be related to Firefox starting.

This isn't the content temp dir, that guid is for the Desktop folder, there are similar error for other known folders.
On my machine it is trying to verify C:\WINDOWS\system32\config\systemprofile\Desktop

I guess this could be related to the sandbox though, so I'll investigate further once I get back to my main win7 machine.
Leaving the needinfo.

Comment 8

[Bob Owen (:bobowen)]

At least in my reproduction of this it appears to be caused by [1].

baku - I don't think we should be doing this in the content process or possibly any child process currently, what do you think?

I could make the calls to OSFileConstantsService::GetOrCreate in the worker code to be parent only, but I'm tempted to put an assertion in OSFileConstantsService::InitOSFileConstants for it to be parent only as well, does that sound correct?

[1] https://searchfox.org/mozilla-central/rev/f41017f5cd7b5f3835d282fbe011d2899574fc2b/dom/workers/RuntimeService.cpp#1836

Comment 9

[Andrea Marchesini [:baku]]

> I could make the calls to OSFileConstantsService::GetOrCreate in the worker
> code to be parent only, but I'm tempted to put an assertion in
> OSFileConstantsService::InitOSFileConstants for it to be parent only as
> well, does that sound correct?

OSFileConstantsService is used to define a set of paths in the ChromeWorker global scope and those can be used in content process.  We should probably check why OSFileConstantsService::InitOSFileConstants wants to create folders and avoid that.

At some point I found a similar issue on linux: bug 1374044. It seems related.

Comment 10

[Bob Owen (:bobowen)]

(In reply to Andrea Marchesini [:baku] from comment #9)
> > I could make the calls to OSFileConstantsService::GetOrCreate in the worker
> > code to be parent only, but I'm tempted to put an assertion in
> > OSFileConstantsService::InitOSFileConstants for it to be parent only as
> > well, does that sound correct?
> 
> OSFileConstantsService is used to define a set of paths in the ChromeWorker
> global scope and those can be used in content process.  We should probably
> check why OSFileConstantsService::InitOSFileConstants wants to create
> folders and avoid that.

I'm slightly surprised by this, we've had to allow some special cases for some file paths in the content process to still have read access, but at least most of those file paths would not be readable in the content process, so why would the JS need them?

It looks like the ones that are causing these issues were added for WebappsInstaller.jsm, which has been removed and aren't used elsewhere.
So I think I can just remove those for this particular bug.

It's the directory service (or to be more precise in this particular case the Windows API) that is attempting to create or at least access the paths, so I'm not sure we can do much about that.
Other than not attempt to get paths that we shouldn't have access to anyway.
 
> At some point I found a similar issue on linux: bug 1374044. It seems
> related.

I think that's a slightly different issue, because this would happen from the parent anyway (I think).

Comment 11

[Andrea Marchesini [:baku]]

> It looks like the ones that are causing these issues were added for
> WebappsInstaller.jsm, which has been removed and aren't used elsewhere.
> So I think I can just remove those for this particular bug.

Ok. Let's try. Do you have a patch I can review?

Comment 12

[Bob Owen (:bobowen)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=bf258a258fce1a93fc6eebab1db27f66d03f54b7

Comment 13

[Bob Owen (:bobowen)]

Attachment: Remove OS.Constants.Path attributes that were added for WebappsInstaller.jsm and no longer used

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a44d31cec728
Remove OS.Constants.Path attributes that were added for WebappsInstaller.jsm and are no longer used. r=baku

Comment 15

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/a44d31cec728