518412 - clipboard data added in Private Browsing Mode causes Windows Explorer to crash when accessing menus which include Paste after closing firefox

Status: RESOLVED FIXED

(Firefox :: Private Browsing, defect)

Description

[daryl.sunderland]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

Firefox is causing frequent Windows Explorer crashes under the RTM version of Windows 7 Ultimate x64.

The Windows Error Reports always point to either 'explorer.exe', 'msvcrt.dll', 'ntdll.dll' or 'comctl32.dll'.

The problem seems to always occur when you either right-click on the desktop, right-click the Recycle Bin, it also happens just as Firefox is closed or when browsing Control Panel

Originally I thought it was Microsoft Security Essentials beta causing the issue, but it was not.
Following advice from a forum I used ShellExView to disable any 3rd party entries, and remove any suspect software.

After several weeks of trying everything possible including re-downloading Windows from Technet and a complete fresh install, somebody suggested that it was Firefox 3.5.2 causing the problem.

Having removed Firefox 3.5.2 the problem stopped.
I decided to try Firefox 3.5.3 to see if the problem was resolved.
As soon as I installed it I started getting the issue again, I have tried Firefox with Add-ons and without and created a new profile, the issue still persists.

Reproducible: Sometimes

Steps to Reproduce:
1. Close Firefox
2. Right-click the desktop or Recycle Bin
Actual Results:  
The issue generally occurs once or twice a day and once it starts Windows will crash on right-click around four times then revert to normal behaviour.

Expected Results:  
Firefox should not make Windows unstable.

about:buildconfig

Source

Built from http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0da982f65d37
Build platform
target
i686-pc-mingw32

Build tools
Compiler 	Version 	Compiler flags
cl 	14.00.50727.762 	-TC -nologo -W3 -Gy -Fdgenerated.pdb -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
cl 	14.00.50727.762 	-GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fdgenerated.pdb -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1

Configure arguments
--enable-application=browser --enable-update-channel=release --enable-update-packaging --enable-jemalloc --enable-official-branding --with-crashreporter-enable-percent=10

Comment 1

[Matthias Versen [:Matti]]

Sorry but this is report is invalid.
Firefox is a usermode application and doesn't change anything in a windows system, no files and no registry settings except the default handler for html files which should not cause such issues.

You can download Firefox as .zip, extract and run Firefox.exe as example.

Please report your issues to Micorsoft, it's their software that is crashing

Comment 2

[daryl.sunderland]

Then there has to be something more sinister going on as Microsoft also deny that it is their fault, and I am inclined to agree.

Install Firefox, issue occurs, remove Firefox, issue goes away.

Something is most certainly not right.

I would appreciate it if several more people were to look into this rather than dismissing it straight off.

Comment 3

[Matthias Versen [:Matti]]

>Then there has to be something more sinister going on as Microsoft also deny
>that it is their fault, and I am inclined to agree.

Their software is crashing not ours.
You can only crash IE as usermode application if you register multimedia codecs for the windows explorer (for the file preview) or if you add something to the context menu like winzip/7-Zip is doing. Firefox isn't doing anything of this, it only registers itself as default application for html files as http/https protocols if you choose that Firefox is the default application.
(Did you try it with IE as default ?)
No system files are replaced and Firefox doesn't put anything in the Windows dll search path.

I don't know if a corrupt icon for a html file or the Firefox application would be able to crash the explorer but such a crash would be a consistent crash.

Again, please report this to Microsoft, only they can find the reason why the explorer is crashing, we can not.

Comment 4

[Gökhan Güleser]

I love firefox very much but this "their software crashing not our thing" is a **** and makes me so angry as a developer..

  This reported issue was seen on two totally different machines while ff 3.5.5 installed and if you uninstall them problem goes away..

I think this problem is so much related to ff then ms.. (I am not a ms fan !!)

Comment 5

[Alice Wyman]

In case it helps,  I've seen a number of people report that the explorer.exe crashes are related to the Firefox 3.5 Private Browsing feature.
Ref:
http://support.mozilla.com/en-US/forum/1/481957
https://support.mozilla.com/en-US/forum/1/503088
http://social.answers.microsoft.com/Forums/en-US/w7performance/thread/f2403318-7bc0-44ca-975b-9ea8db11e779#3448e2e7-5a8e-4560-b7a6-0c13001d6482

Comment 6

[daryl.sunderland]

Yes, I now believe that this issue is indeed related to the Private Browsing feature and can confirm that the issue is present in both the current 3.5 release and the beta 3.6b3 release.

Turning off this feature and having Firefox remember my history seems to resolve the issue.

There is obviously some issue where as whatever is being dumped from RAM at the end of the Private Browsing session is causing Explorer to crash repeatedly.

I can confirm this also happens when 'Never Remember History' is selected, as well as 'Custom' settings with Private Browsing enabled.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Daryl: it would help if you could list some "Steps to Reproduce" (aka: STR) which can be followed to reliably produce the problem you're describing.

Also: does this only happen on Windows 7 64-bit, or have there been reports of it on 32-bit as well?

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

FWIW, I can't reproduce this at all with any of the steps in comment 0. I can't block on this until we get confirmed steps to reproduce. Once we have those, please feel free to renominate.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

http://www.neowin.net/forum/index.php?showtopic=844700 indicates that it might be related to AntiVirus software or other things that insert themselves into the context menu. It's possible, I suppose, that Private Browsing mode might be removing some data that those applications have a handle on?

I'd really like to reproduce this, but can't seem to be able to yet. :(

Comment 10

[daryl.sunderland]

Hello Mike,

As far as I know the issue only occurs under Windows 7 Professional and Ultimate edition x64 RTM, of which I am running the latter.

I can reproduce the issue as follows:

If I set Firefox (3.5.5 or 3.6b3) to 'Never remember history' or 'Use custom settings for history' and have 'private mode' enabled automatically, when I close the session then right-click on the desktop or the Recycle Bin, Windows Explorer will crash.

I have been affected by this issue since Windows 7 RTM hit Technet, it almost always happens daily and since setting Firefox to 'Remember history' my machine has been solid for over two days. I am still testing and intend to leave it for at least five days before I am 100% sure.

I have zero shell extensions enabled, having disabled them all with ShellExView.

I guess the problem is when whatever has been held in memory as part of 'private mode' gets dumped as opposed to being stored on the local hard drive.

Comment 11

[(no longer active)]

Daryl, do you also see this issue when you enter private browsing mode from a normal session?

Adding Henrik and Marcia to see if they're able to reproduce this.  (I wasn't, but I don't have Win7 x86-64.)

Comment 12

[juan becerra [:juanb]]

On a Win7 Professional 32bit VM, I cannot recreate the problem using 3.5.5/3.6b3 using the steps in comment#10. I've only been trying to get it in that state for a half hour or so.

Results on hardware machines and 64bit Win7 are coming up.

Comment 13

[u88484]

I can't reproduce this using latest trunk or Firefox 3.5.5 with new profile while on Windows 7 Home Premium x64.  I tried 10 times with each build using the same initial profile.

After first start, I changed the setting for Firefox to not remember history, restarted firefox and began "browsing" by loading about eight random pages in different tabs and clicking a bunch of links on each page, closing Firefox and right-clicking on the desktop and then the recycle bin (I rotated which area I right-clicked each time).

Comment 14

[juan becerra [:juanb]]

Some of the forums link to reports in Microsoft forums (http://bit.ly/4JBXtT) where there is no reference to Firefox. They do talk about an "nvidia cpl context menu extension" which when disabled seem to fix the problem.

Daryl, when you run the ShellExView do you see that item there under Context Menu items?

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Daryl, can you do us a favor? If the Explorer is crashing it would be worth a try to get the stack with a debugger. The following link is mostly related for Firefox but should also help you with the Explorer. Please follow the steps and attach a stacktrace on that bug. Thanks!

https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg

Comment 16

[daryl.sunderland]

Hey,

I really appreciate all your help with this issue, guys.

I do not have any NVIDIA hardware and therefore do not have that specific entry.

I have disabled every entry there using ShellExView bar the default Microsoft entries.

I can confirm that this issue does not occur under Windows 7 x86 (tested with Ultimate and Home Premium).

As far as I know it is (at least from what I have heard) only Windows 7 x64 Professional and Ultimate RTM that are affected. I am running the latter.

Interestingly, I never experienced this issue with the beta and RC builds of Windows 7.

I have seen the issue occur with both Firefox 3.5.5 (and 3.5.3 and 3.5.4) as well as 3.6b3.

It does not happen with Firefox 3.0.x.

I am currently trying to get a stack but typically when I want it to crash, it simply won't. I shall continue to try, oddly enough around a week ago it was reproducible almost every time.

In the meantime I am going to upload a dump from WinDbg from when explorer.exe crashed and someone said it was heap corruption. I am not sure if it will help, but it is the same issue.

Daryl.

Comment 17

[daryl.sunderland]

Attachment: Explorer crash dump.

Comment 18

[daryl.sunderland]

http://support.mozilla.com/en-US/forum/1/447377
 
http://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=393109&forumId=1
 
http://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=441328&forumId=1
 
http://forums.mozillazine.org/viewtopic.php?f=9&t=1350255&sid=e5aa9207f253a9bbd8d8b8bc43910ee2&start=15

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #17)
> Created an attachment (id=414392) [details]
> Explorer crash dump.

Josh, is this mini dump helpful to get more information what's going on here?

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #19)
> (In reply to comment #17)
> > Created an attachment (id=414392) [details] [details]
> > Explorer crash dump.
> 
> Josh, is this mini dump helpful to get more information what's going on here?

Once again and now with Josh cc'ed.

Comment 21

[u88484]

(In reply to comment #13)
> I can't reproduce this using latest trunk or Firefox 3.5.5 with new profile
> while on Windows 7 Home Premium x64.  I tried 10 times with each build using
> the same initial profile.
> After first start, I changed the setting for Firefox to not remember history,
> restarted firefox and began "browsing" by loading about eight random pages in
> different tabs and clicking a bunch of links on each page, closing Firefox and
> right-clicking on the desktop and then the recycle bin (I rotated which area I
> right-clicked each time).

I was actually able to make explorer crash yesterday after about an hour of browsing with history set to never remember.  I also crashed about 15 minutes later with the same setup but I was just browsing at the time using and had not closed firefox.  I had copied and pasted some text from a comment I was making on bugzilla into notepad using shortcut keys.  When I switched back to Firefox, explorer crashed.

Comment 22

[timeless]

oh, don't worry, i was going to read this anyway.

0:039> !lmi NLSLexicons0009 
Loaded Module Info: [nlslexicons0009] 
Cannot read Image header @ 00000000690f0000
    Load Report: no symbols loaded
0:039> !lmi shellext   
Loaded Module Info: [shellext] 
         Module: shellext
   Base Address: 000000006a790000
     Image Name: shellext.dll
   Machine Type: 34404 (X64)
     Time Stamp: 4aad91f9 Mon Sep 14 03:44:41 2009
           Size: 75000
       CheckSum: 8093d
Characteristics: 2022  
Debug Data Dirs: Type  Size     VA  Pointer
             CODEVIEW    25,  8db8,    81b8 RSDS - GUID: {FBC65295-F793-40B8-BCC9-BE933F5CCDAA}
               Age: 1, Pdb: shellext.pdb
     Image Type: FILE     - Image read successfully from debugger.
                 shellext.dll
    Symbol Type: EXPORT   - PDB not found
    Load Report: export symbols
0:039> !lmi WLCShell 
Loaded Module Info: [wlcshell] 
Cannot read Image header @ 000000006a900000
    Load Report: no symbols loaded
0:039> !lmi MoeHostPS
Loaded Module Info: [moehostps] 
Cannot read Image header @ 000000006b730000
    Load Report: no symbols loaded
0:039> !lmi FXSRESM
Loaded Module Info: [fxsresm] 
Cannot read Image header @ 00000000706c0000
    Load Report: no symbols loaded
0:039> !lmi ZuneTaskbar
Loaded Module Info: [zunetaskbar] 
Cannot read Image header @ 0000000070c90000
    Load Report: no symbols loaded
0:039> !lmi slc      
Loaded Module Info: [slc] 
Cannot read Image header @ 000007fefa5c0000
    Load Report: no symbols loaded
0:039> !lmi dui70
Loaded Module Info: [dui70] 
Cannot read Image header @ 000007fefb3a0000
    Load Report: public symbols , not source indexed 
                 c:\symbols\DUI70.pdb\5E6C1900D2E04D338B6D5989677DDC3E2\DUI70.pdb


FAULTING_IP: 
ntdll!RtlReportCriticalFailure+2f
00000000`76e06c9f cc              int     3

EXCEPTION_RECORD:  ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000076e06c9f (ntdll!RtlReportCriticalFailure+0x000000000000002f)
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 1
   Parameter[0]: 0000000000000000

DEFAULT_BUCKET_ID:  STATUS_BREAKPOINT

PROCESS_NAME:  explorer.exe

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid

EXCEPTION_PARAMETER1:  0000000000000000

APPLICATION_VERIFIER_FLAGS:  0

LAST_CONTROL_TRANSFER:  from 0000000000000000 to 0000000076dad1cd

FAULTING_THREAD:  ffffffffffffffff

PRIMARY_PROBLEM_CLASS:  STATUS_BREAKPOINT

BUGCHECK_STR:  APPLICATION_FAULT_STATUS_BREAKPOINT

STACK_TEXT:  
00000000`76dad1cd ntdll! ?? ::FNODOBFM::`string'+0x123b4
00000000`76b42c7a kernel32!HeapFree+0xa
000007fe`fb3b095e dui70!DirectUI::DUIXmlParser::CreateStyleSheet+0x212
000007fe`fb3b0fe4 dui70!DirectUI::DUIXmlParser::ParseStyleSheets+0x1a9
000007fe`fb3b0e5a dui70!DirectUI::DUIXmlParser::InitializeParserFromXmlLiteReader+0x154
000007fe`fb3ad007 dui70!DirectUI::DUIXmlParser::SetPreprocessedXML+0x1c1
000007fe`fb3ace52 dui70!DirectUI::DUIXmlParser::SetXML+0xd9
000007fe`f1344b82 EXPLORERFRAME!DUI_CreateParserWithCallbackFromResource+0x95
000007fe`f135f9a5 EXPLORERFRAME!DUI_CreateParserFromResource+0x15
000007fe`f135f941 EXPLORERFRAME!InitItemsviewParserForThread+0x5d
000007fe`f135f8ac EXPLORERFRAME!ItemsViewInit+0xac
000007fe`f135f7c4 EXPLORERFRAME!CItemsView::CreateControl+0x40
000007fe`fe157292 shell32!CDefView::_OnCreate+0x139
000007fe`fe157171 shell32!CDefView::WndProc+0x1b4
000007fe`fe1b1393 shell32!CDefView::s_WndProc+0x7c
00000000`76c5b601 user32!UserCallWinProcCheckWow+0x163
00000000`76c5a01b user32!DispatchClientMessage+0xc3
00000000`76c52bb5 user32!_fnINLPCREATESTRUCT+0xc0
00000000`76d8fdf5 ntdll!KiUserCallbackDispatcherContinue+0x0
00000000`76c5255a user32!NtUserCreateWindowEx+0xa
00000000`76c529d7 user32!VerNtUserCreateWindowEx+0x27c
00000000`76c52718 user32!CreateWindowEx+0x404
00000000`76c52ca0 user32!CreateWindowExW+0x70
000007fe`fe1546f7 shell32!SHFusionCreateWindowEx+0xae
000007fe`fe15699f shell32!CDefView::CreateViewWindow3+0x46e
000007fe`f13830fc EXPLORERFRAME!FileCabinet_CreateViewWindow2+0x4db
000007fe`f1382f1f EXPLORERFRAME!CShellBrowser::CreateViewWindow+0xb7
000007fe`f1383376 EXPLORERFRAME!CShellViewFactory::_CreateNewConnection+0x182
000007fe`f13827cf EXPLORERFRAME!CShellViewFactory::BeginCreateConnection+0xf8
000007fe`f1382dde EXPLORERFRAME!CShellBrowser::_CreateConnectionForItem+0x36d
000007fe`f1382a3a EXPLORERFRAME!CShellBrowser::_CreateNewConnection+0xd9
000007fe`f1382946 EXPLORERFRAME!CShellBrowser::_NavigateToPidl+0x167


FOLLOWUP_IP: 
dui70!DirectUI::DUIXmlParser::CreateStyleSheet+212
000007fe`fb3b095e ??              ???

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  dui70!DirectUI::DUIXmlParser::CreateStyleSheet+212

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: dui70

IMAGE_NAME:  dui70.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bdf25

STACK_COMMAND:  !heap ; dds 76e7c458 ; kb

FAILURE_BUCKET_ID:  STATUS_BREAKPOINT_80000003_dui70.dll!DirectUI::DUIXmlParser::CreateStyleSheet

BUCKET_ID:  X64_APPLICATION_FAULT_STATUS_BREAKPOINT_dui70!DirectUI::DUIXmlParser::CreateStyleSheet+212

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/explorer_exe/6_1_7600_16404/4a765771/ntdll_dll/6_1_7600_16385/4a5be02b/80000003/000c6c9f.htm?Retriage=1

Followup: MachineOwner
---------

dui70 is "Windows DirectUI Engine" not to be confused with any other vendor's products with similar names....

The reporter should contact Microsoft. I probably could contact them, but it'd just make me a middle man.

Comment 23

[chrisorsatti]

I guess the workaround is to use IE until MS fixes it.  Is that what Mozilla is saying?

Comment 24

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I'll follow up with Microsoft on this issue.  I don't think that there is anything we can do to resolve it on our end, especially since we can't reproduce the problem.

Using another browser, or not using Private Browsing Mode, would indeed be a way to work around it if your system is crashing in this way.  It would also be interesting to know if the problem persists with Firefox 3.6 betas.

Comment 25

[daryl.sunderland]

The problem does indeed persist with the 3.6 beta, at the very least 3.6b2 and 3.6b3.

I have tried to relay this to Microsoft on several occasions without success.

Kurt Schultz seems to have reproduced the problem, the majority of Windows Explorer crashes seem to happen after the browser has been closed and then you right-click something, however I have known it to crash randomly at times.

So if this is a Microsoft problem, how does Internet Explorer and Google Chrome manage to perform private sessions with no adverse effect?

Sadly, since Microsoft refuse to accept it is there problem, then in fact what we're really saying is ditch Firefox and go with Internet Explorer or Chrome.

Can I just double check that everyone who has tried or is trying to reproduce this problem is using either Windows 7 Professional or Ultimate x64 RTM, and NOT an x86 version or VM. Also, I have seen no reports of this affecting any of the lesser x64 editions.

Comment 26

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Yeah, I'm on Ultimate 64 on one machine, and Professional 64 on the other, both RTM.  No dice.

Comment 27

[daryl.sunderland]

Fair enough.

Well I guess unless more people come forward that can reproduce this, then we're dead in the water.

Thank you for all the help.

Comment 28

[Mark Greenlay]

I'm able to reproduce the explorer crash pretty consistently, but I usually have to run Firefox in Private Browsing mode for an hour or two.  Then after closing Firefox I'm able to trigger it by closing an explorer window or by right clicking.  

I've done it with 3.55 and 3.6b2 on Windows 7 Ultimate x64.  I was also having the same problem on Vista Ultimate x64, but this was before people figured out the Firefox 3.5x connection, so I didn't do any testing at the time.

I've been trying to do it with a x64 version of Firefox (http://wiki.mozilla-x86-64.com/Firefox:Download), but so far it doesn't seem to suffer from this problem.

Comment 29

[timeless]

so, i'd be vaguely interested in what historically would have been a filemon log, but for w7 would be procmon (sysinternals.com) just file open/close/read logging and only fore explorer.exe (somewhere you'll find documentation on how to use procmon so that it doesn't overload your computer).

Comment 30

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Daryl or Mark, can you both try to run Firefox 3.5 or 3.5.1 and check if the problem persists with that version?

Comment 31

[Fish]

I'm experiencing this bug too. Reference here - http://www.neowin.net/forum/index.php?showtopic=844700&st=105&p=591889884&#entry591889884

Windows 7 Home Premium 64 bit
Firefox 3.5.5

After a previous (lengthy?) private browsing session, I can crash Explorer by simply right-clicking on the desktop.

Cannot be sure now, but I think this was also happening with Vista 64 bit and previous version of Firefox.

Comment 32

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Fish, can you please check the mentioned builds in comment 30 too?

Comment 33

[Radek 'sysKin' Czyz]

I stumbled upon this bug by accident and decided to try to reproduce. I was successful the very first time.

What I did:
1. Start FF private browsing mode
2. Go to some website. I wish I could be more specific.
3. Copy something to clipboard. I wish I could be more specific on that one too.
4. Close firefox
5. Right click on desktop

Actual results: explorer.exe crash every time, I got several of those.

6. Now copy something else to clipboard

Actual results: no more crashes.

I was not able to reproduce ever since.

Firefox does clear its own clipbard data when exiting PB mode. My conclusion from the above is that it's doing it in such a way that explorer.exe is no longer able to process the clipboard (which it does when right-clicking, it has a "paste" there) without dying.
And that's logical too, as clipbard is about the only thing Firefox can leave behind after closing.

Comment 34

[timeless]

syskin:
what version of windows are you using?
when explorer crashes, does wordpad crash if you try to paste into it?

Comment 35

[Mark Greenlay]

(In reply to comment #30)
> Daryl or Mark, can you both try to run Firefox 3.5 or 3.5.1 and check if the
> problem persists with that version?

I can confirm that it happens with both 3.5 & 3.5.1

Comment 36

[Steve]

I believe I have the solution to this - reinstalling the Visual C++ redistributable appears to fix this problem.
I'm not sure but I think the problem lies in something msvcrt.dll is doing, anyhow this seems to fix it.

Tested on two seperate x64 Windows 7 Ultimate machines.

Comment 37

[Radek 'sysKin' Czyz]

@timeless: right, I forgot.
Windows is 7 home premium x64.
Firefox is Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091127 Minefield/3.7a1pre (ie yesterday's nightly).

I currently can't reproduce any more, but will try later today and will use some proper tools to investigate the clipboard.

Comment 38

[Radek 'sysKin' Czyz]

> when explorer crashes, does wordpad crash if you try to paste into it?

OK I reproduced that another three times after which it's not crashing anymore, again.
Simplest steps I found so far were:
1. Start PB mode
2. On the PB welcome screen, highlight some text and copy it
3. Close Firefox
4. Right click on desktop.

While explorer is crashing, no other program allows pasting at all - it's as if clipboard was really empty.
I also used a freeware program ClipSpy. After I copy something, the clipboard has three formats - CF_TEXT and CF_UNICODETEXT with what I copied, as well as another thingy named application/x-moz-private-browsing which has no data.
After I close Firefox all three items disappear and clipboard appears to be completely empty, as far as ClipSpy can see.

Sooo all that appears to be as expected, except the crash :/

Comment 39

[David Kidwell]

(In reply to comment #33)
> I stumbled upon this bug by accident and decided to try to reproduce. I was
> successful the very first time.
> 
> What I did:
> 1. Start FF private browsing mode
> 2. Go to some website. I wish I could be more specific.
> 3. Copy something to clipboard. I wish I could be more specific on that one
> too.
> 4. Close firefox
> 5. Right click on desktop
> 
> Actual results: explorer.exe crash every time, I got several of those.
> 
> 6. Now copy something else to clipboard
> 
> Actual results: no more crashes.
> 
> I was not able to reproduce ever since.
> 
> Firefox does clear its own clipbard data when exiting PB mode. My conclusion
> from the above is that it's doing it in such a way that explorer.exe is no
> longer able to process the clipboard (which it does when right-clicking, it has
> a "paste" there) without dying.
> And that's logical too, as clipbard is about the only thing Firefox can leave
> behind after closing.

I have been having this "crash" issue for quite a while now with both Vista x64 and Windows 7 x64. I can also Confirm that this does effect the CLIPBOARD as I was trying to copy some date into a text document on my desktop and when I closed FF I was unable to paste what I had copied. I'm sure that is what FF's privacy settings are designed to do - clear the clipboard. I do use privacy settings ON.
So, this does bring us to a place where FF and MS DO meet. Contrary to post #1.
The clipboard is being used by BOTH and I think this may be the culprit. As previously stated the right-mouse-click function calls for the clipboard's use..(the COPY/PASTE functions).
I don't know if I would say that Wordpad or any other app is having issues "with it" or if they actually crash...you just lose the ability to paste or right click most/some of the time. The randomness of this particular crash is the real head-scratcher for me...although now that I think about it...it might be that I haven't used the copy/paste functions of FF or MS; or not in the right order to create the error.

By Jove, I think were getting somewhere on this issue.
I have been working almost non-stop for weeks on this.

Comment 40

[David Kidwell]

I was able to duplicate the error by simply copying text from a random web site and then closing FF and using the right-mouse button. It doesn't allways happen right away but if you click a few times...BINGO! Error. (not very scientific I know, but it does cause the error and I can go all day without seeing it and I just made it happen 30 seconds after a re-boot.) not usually the case in my experience. 

PS:I have been using ONLY the retail versions of Vista x64 and Windows 7 x64. (both are home prem editions).

Comment 41

[timeless]

ok, since this is really just windows 7 x64 and since we have those fields as fields, i'm cleaning up the summary.

http://mxr.mozilla.org/mozilla-central/source/widget/src/xpwidgets/nsClipboardPrivacyHandler.cpp

is the file, and it kinda explains what it's doing.

Comment 42

[David Kidwell]

I'm not sure what your trying to say. If your saying that FF has fixed the problem or potential for the problem or, FF never had a problem in the first place and its an OS issue with MS.
 But, in either case I believe we have finally hit on something here. Maybe, MS has some bad memory handling coding or have failed to divulge the proper coding information to 3rd party software developers.
If I were a betting man,(and I am), I would bet its one or both of these scenarios. It looks to me (a retired programmer),like a memory block is not being properly protected or there is a size issue causing data to overlap or be overwritten. This would explain the myriad of dumps referring to a "Heap corruption" issue, and the way just about every app is effected, AND why its so hard to "force" an error or reproduce...as some times there just isn't corruption taking place.
 I've been out of the programming loop for a while, so I'm not entirely sure, but I believe the "Heap" is a memory object.

Comment 43

[daryl.sunderland]

I would have to agree with you there David.

Could you try and explain a little more clearly please timeless?

I can confirm that this issue does occur under Firefox 3.5 and 3.5.1.
So for me, that's every version of 3.5, and every beta of 3.6 where I have experienced this issue.

Since turning off private mode I have enjoyed nearly four days without issue.

I see people are now saying that it 'might' be a problem with the Visual C++ runtime, I am not going to tempt fate unless it happens again with private mode off, if it does, then I will try reinstalling the Visual C++ runtime.

I have tried to reproduce the error with the clipboard, using Notepad and Wordpad, but cannot.

Hopefully we're getting somewhere now.

Thank you all, and keep up the good work!

Comment 44

[u88484]

Can someone please download a trunk nightly from March 27, 2009 and attempt to reproduce it a build before the "clear data copied to clipboard inside private browsing mode" patch landed.  And then try the March 28, 2009 build since that is the first build to contain the patch.

Same thing with the branch but the March 28 and March 29, 2009 builds.

Trunk nightly:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/03/2009-03-27-06-mozilla-central/
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/03/2009-03-28-04-mozilla-central/

Branch nightly:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/03/2009-03-28-04-mozilla-1.9.1/
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/03/2009-03-29-04-mozilla-1.9.1/

Make sure you use a new profile!!

Comment 45

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: windbg output from crash

Comment 46

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: call stack from crash

Comment 47

[(no longer active)]

So, I finally managed to reproduce this and catch it under WinDbg using Beltzner's Win7 x64 VM.  He attached the cal stack (attachment 415211 [details]) and full WinDbg log (attachment 415210 [details]) to the bug.

In order to reproduce this, I opened Firefox 3.6b3 (the version shouldn't really matter) in permanent private browsing mode, copied some text off of a web page, closed Firefox, and right clicked on the desktop quite a few number of times (perhaps 20-30 times) until I got Explorer to crash.

We're talking with some Microsoft contacts on this issue, and I will forward them the log to see if they can help us here.

Comment 48

[Justin Dolske [:Dolske]]

Random thought: When I implemented the Windows CE clipboard, I had to handle the private data flag as a bit of a special case. IIRC, it was a little inconvenient because the CE clipboard only gave you a pointer (no length), so the caller has to know what the data format is for a given flavor. The win32 code was quite different, I don't remember if it had this limitation or not.

So, as a wild guess, I wonder if the crash here (which looks like heap corruption) might be because something is assuming the clipboard data for this flavor is a string, and ends up getting confused. Maybe try a quick hack to use a string as the transferable data, and see if that wallpapers over MS's crash?

Comment 49

[(no longer active)]

(In reply to comment #48)
> Random thought: When I implemented the Windows CE clipboard, I had to handle
> the private data flag as a bit of a special case. IIRC, it was a little
> inconvenient because the CE clipboard only gave you a pointer (no length), so
> the caller has to know what the data format is for a given flavor. The win32
> code was quite different, I don't remember if it had this limitation or not.
> 
> So, as a wild guess, I wonder if the crash here (which looks like heap
> corruption) might be because something is assuming the clipboard data for this
> flavor is a string, and ends up getting confused. Maybe try a quick hack to use
> a string as the transferable data, and see if that wallpapers over MS's crash?

I created a build with what you suggested in this comment, it's available at:

<http://ehsanakhgari.org/sites/default/files/file/mozilla/bug/518412/trial-fix.zip>

(It's a debug build which includes a lot of test stuff, but you can pay no attention to them and just run firefox.exe.)

It would be great if the people who have seen this problem can give this build a test.

Comment 50

[(no longer active)]

(In reply to comment #49)
> <http://ehsanakhgari.org/sites/default/files/file/mozilla/bug/518412/trial-fix.zip>

This won't help you if you don't have VC installed, so you can probably try this build instead:

<https://build.mozilla.org/tryserver-builds/[e-mail]-try-0c88c5aff53f/try-0c88c5aff53f-win32.zip>

Comment 51

[(no longer active)]

(In reply to comment #48)
> So, as a wild guess, I wonder if the crash here (which looks like heap
> corruption) might be because something is assuming the clipboard data for this
> flavor is a string, and ends up getting confused. Maybe try a quick hack to use
> a string as the transferable data, and see if that wallpapers over MS's crash?

I managed to reproduce the problem multiple times with my trial build, so I can confirm that it has not solved the crash.

Comment 52

[sullysnet]

I have reported this a few times on a few different boards and I had uploaded dump there and filemon logs. I can post them here as well if it helps out.
http://rapidshare.com/files/306695076/Logs.zip

Hopefully someone is solved because I do use Firefox everyday and it was great to move to x64, finally.

I will have to try out one of the builds and see what I get

thanks

Comment 53

[(no longer active)]

Our Microsoft contacts have confirmed this to be a bug on the Windows clipboard handling code, and have suggested a couple of workarounds for us, until they get the problem fixed on their side.

1. Leaving an application/x-moz-privatebrowsing item on the clipboard, which would still clear the clipboard effectively because no other application knows about that type, and therefore the clipboard will be empty as far as any application is concerned.

2. Using the EmptyClipboard Win32 API on Windows.

The first workaround actually imposes a privacy risk for us (because it allows applications to tell whether some data had been copied inside the private browsing mode after leaving that mode), so I'm going to try the second workaround.

Now that we have a clear set of steps to reproduce, and a patch, I think we should block on this for all branches that ship the private browsing code, which would be trunk, 1.9.2 and 1.9.1.

Comment 54

[(no longer active)]

Attachment: Workaround

This workaround uses OleSetClipboard instead of EmptyClipboard, because the MSDN mentions that calling EmptyClipboard without a window handle for OpenClipboard might cause future attempts to set the clipboard data to fail.

Comment 55

[timeless]

ehsan: did they give you a ticket number or update any msdn page?

as a footnote.. apps running as the same user can use mouse/screen/window apis or accessibility apis to determine if we're in private browsing, so we shouldn't actively worry about such cases. - i'm not opposed to working around this, just noting that trying to compete with other apps on the same system isn't productive.

Comment 56

[(no longer active)]

Comment on attachment 415533 [details] [diff] [review]
Workaround

I think we should land this on m-c, and port it back to 1.9.2 if possible this week.

Comment 57

[(no longer active)]

(In reply to comment #55)
> ehsan: did they give you a ticket number or update any msdn page?

No, unfortunately not.  And they didn't have an ETA on when the fix would be available on their side.

> as a footnote.. apps running as the same user can use mouse/screen/window apis
> or accessibility apis to determine if we're in private browsing, so we
> shouldn't actively worry about such cases. - i'm not opposed to working around
> this, just noting that trying to compete with other apps on the same system
> isn't productive.

Yes, I understand that, but this is trying to protect against the case where the private session has ended (and possibly, when Firefox has been closed).  In addition, this was actually the easier solution to implement.  :-)

Comment 58

[Mike Beltzner [:beltzner, not reading bugmail]]

Family <3 Ehsan

Comment 59

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/bdcf3b218755

Will land on 1.9.2 tomorrow morning if this cycles green.

Comment 60

[Brad Lassey [:blassey] (use needinfo?)]

looks like this broke winmo.  The simple fix is to change #ifdef XP_WIN to #if defined(XP_WIN) && !defined(WINCE)

Comment 61

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: winmo bustage fix

Comment 62

[Brad Lassey [:blassey] (use needinfo?)]

turns out this broke all of the windows builders, backed out: http://hg.mozilla.org/mozilla-central/rev/96c38734ae24

Comment 63

[(no longer active)]

(In reply to comment #62)
> turns out this broke all of the windows builders

Did it?  I only see failures on WinCE builders on Tinderbox, and I think your patch (attachment 415808 [details] [diff] [review]) would have fixed the issue.

Comment 64

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to comment #63)
> (In reply to comment #62)
> > turns out this broke all of the windows builders
> 
> Did it?  I only see failures on WinCE builders on Tinderbox, and I think your
> patch (attachment 415808 [details] [diff] [review]) would have fixed the issue.

you're right. I was confused by the fact that tbpl mixes the wince firefox builders in with the windows desktop builders.

Comment 65

[(no longer active)]

Attachment: Bustage fixed

This combines blassey's bustage fix patch with my original patch.  I'll push it tomorrow morning, because I won't stay around long enough to watch the tree.

Comment 66

[[e-mail]]

Comment on attachment 415811 [details] [diff] [review]
Bustage fixed

>+      NS_ENSURE_TRUE(S_OK == ::OleSetClipboard(NULL), NS_ERROR_FAILURE);
Use SUCCEEDED()

Comment 67

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/98f511e69594
http://hg.mozilla.org/mozilla-central/rev/4f6dd3dbccaf (addresses comment 66)

Comment 68

[(no longer active)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/f145c7bfeb44

Comment 69

[(no longer active)]

Attachment: As pushed

Comment 70

[daryl.sunderland]

Thank you very much for all of your hard work, I'm so pleased that this can finally be laid to rest.

After a rocky start, the Mozilla team have worked wonders, and I am hoping Microsoft will follow suit.

I am ever so grateful.

Does anybody know if this fix will be included in Firefox 3.6b5?
If not, then which release is it likely to make it into first?

Thanks again,

Daryl Sunderland.

Comment 71

[u88484]

It doesn't look like it made beta 5, but will definitely be in beta 6 or the RC (which ever one is decided to be next).

Comment 72

[Daniel Veditz [:dveditz]]

Comment on attachment 415932 [details] [diff] [review]
As pushed

Approved for 1.9.1.7, a=dveditz for release-drivers

Does this lead to clipboard dataloss that users will start complaining about?

Comment 73

[(no longer active)]

(In reply to comment #72)
> (From update of attachment 415932 [details] [diff] [review])
> Approved for 1.9.1.7, a=dveditz for release-drivers
> 
> Does this lead to clipboard dataloss that users will start complaining about?

Firefox clears the clipboard data (if it is copied from within Firefox) when leaving the private browsing mode, and this patch does not affect that behavior.  The only thing that this patch does is make sure that Explorer won't crash on Win7 64-bit after we do that.

Can I go ahead and land this on 1.9.1?

Comment 74

[Samuel Sidler (old account; do not CC)]

Land away!

Comment 75

[(no longer active)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/77abc69fbd94

Comment 76

[nvd]

Thanks for providing solution. But was this fix included in latest 3.5.6 or 3.5.7 releases?

Comment 77

[(no longer active)]

The fix will be included in Firefox 3.5.8, whenever it is released, and also Firefox 3.6, which will be released soon.

Comment 78

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Marking the 14 bugs that are both:
 * nominated for blocking1.9.3:?
 * fixed on the 1.9.2 branch (according to status1.9.2)
as blocking1.9.3:alpha1, so that we don't have to go through the nominations individually.  They're all fixed already (so there's no work to do), and being fixed on 1.9.2 means they probably do block 1.9.3.