131857 - Setting Mozilla as Default Mail app crashes - Trunk [@ nsLocalFile::InitWithPath]

Status: VERIFIED FIXED

(MailNews Core :: Simple MAPI, defect)

Description

[Kevin Chen]

Each time I start Mozilla Mail, I get the message asking whether I want to set
it as the default mail application.  If I click Yes, I get the following message:

"Mozilla Mail could not be set as the default mail application because a
registry key could not be updated.  Verify with your system administrator that
you have write access to your system registry, and then try again."

I'm using Mozilla 0.9.9 (build 2002031104).  Since I'm using Win98, there should
be no registry writing issues.

Comment 1

[Kevin Chen]

This problem is still occurring for me on 2002042403 on Win98.

Here are some more things I tried:

In Internet Explorer's Internet Options in Control Panel, I set the default mail
program to "Mozilla 1.0.0+ Mail" (Help->About Mozilla reports 0.9.9+ though--no
other option in the Internet Options).

In the preferences, under Mail & Newsgroups, I checked the box to set Mozilla
Mail as the default mail application.

After performing either (or both) of these steps, I still get the same error
message.  In the second instance, I get the same error message right when I
click OK to exit the preferences box (and then the Preferences box does not
close until I uncheck it).

Comment 2

[Kevin Chen]

I just downloaded 2002042908 today.  (Did not occur on 2002042608.)

If I click the Yes button upon starting Mozilla mail, Mozilla crashes.
Talkback IDs:
TB5751934E
TB5751923K

This is reproducible.

If I click the checkmark in preferences, nothing happens.

Clicking Start->Run and typing mailto:someaddress launches Netscape 4.79 instead
of Mozilla.  Deafult mail program under Internet Explorer's Internet Options
says "Mozilla 1.0.trunk Mail."

Comment 3

[Kevin Chen]

Still occurs on 2002050408.
Talkback for this build: TB5940142

Increasing severity to critical and adding crash keyword as a result of crash.

Comment 4

[Jay Patel [:jay]]

This has been a topcrasher on the MozillaTrunk for a while now.  A lot of users
are crashing setting Mozilla as the default mail client:

nsLocalFile::InitWithPath   25 
BBID range: 5684282 - 5940142
Min/Max Seconds since last crash: 8 - 23349
Min/Max Runtime: 15 - 100330
Crash data range: 2002-04-27 to 2002-05-04
Build ID range: 2002042708 to 2002050308
Keyword List : mail(7), click(4), crash(4), 
Stack Trace: 

	 nsLocalFile::InitWithPath
[nsLocalFileCommon.cpp  line 348]
	 nsMapiRegistryUtils::CopyMozMapiToWinSysDir
[nsMapiRegistryUtils.cpp  line 384]
	 nsMapiRegistryUtils::setDefaultMailClient
[nsMapiRegistryUtils.cpp  line 473]
	 nsMapiRegistry::ShowMailIntegrationDialog
[nsMapiRegistry.cpp  line 122]
	 nsMapiRegistryUtils::nsMapiRegistryUtils
[nsMapiRegistryUtils.cpp  line 68]
	 XPTC_InvokeByIndex
[xptcinvoke.cpp  line 106]
	 XPCWrappedNative::CallMethod
[xpcwrappednative.cpp  line 1995]
	 XPC_WN_CallMethod
[xpcwrappednativejsops.cpp  line 1267]
	 js_Invoke
[jsinterp.c  line 797]
	 js_Interpret
[jsinterp.c  line 2764]
	 js_Execute
[jsinterp.c  line 977]
	 JS_EvaluateUCScriptForPrincipals
[jsapi.c  line 3366]
	 nsJSContext::EvaluateString
[nsJSEnvironment.cpp  line 703]
	 GlobalWindowImpl::RunTimeout
[nsGlobalWindow.cpp  line 4479]
	 GlobalWindowImpl::TimerCallback
[nsGlobalWindow.cpp  line 4844]
	 nsTimerImpl::Fire
[nsTimerImpl.cpp  line 345]
	 USER32.DLL + 0x580d (0xbfc0580d)
	 nsAppShell::Run
[nsAppShell.cpp  line 116]
	 nsAppShellService::Run
[nsAppShellService.cpp  line 451]
	 main1
[nsAppRunner.cpp  line 1472]
	 main
[nsAppRunner.cpp  line 1808]
	 WinMain
[nsAppRunner.cpp  line 1826]
	 WinMainCRTStartup()
	 KERNEL32.DLL + 0x1b560 (0xbff8b560)
	 KERNEL32.DLL + 0x1b412 (0xbff8b412)
	 KERNEL32.DLL + 0x19dd5 (0xbff89dd5)
 
 	Source File : nsLocalFileCommon.cpp line : 348
     (5825854)	Comments: Possible problem with the mailreader on 5/1 trunk
     (5819848)	Comments: With mozilla closed  I renamed mapi32.dll to mapi32.dll.moz.  I
then opened mozilla  and went to the mail app - it detected that it wasn't the
default mail app and asked if I wanted it to be the default app.  I clicked Yes
and it crashed.
     (5819755)	Comments: With Moz dead  I renamed the mapi32.dll to mapi32.dll.bak  and
renamed mapi32bak.dll (the old mapi) to mapi32.dll.  Then I reran mozilla  went
to edit prefs  and selected mozilla as the default mail application.  It crashed
when I clicked OK  and it did
     (5819755)	Comments:  not rename mapi32.dll.
     (5819642)	Comments: same as before.
     (5819598)	Comments: I was running the current build when I tried to send an email from
within Excel.  It said it couldn't do it  so I went to edit/prefs and tried to
remove Mozilla as the default mail app - whenever I unchecked it and clicked OK
 when I went back into prefs 
     (5819598)	Comments:  it was still checked.  Unchecking again didn't do anything  so I
bounced mozilla  went into prefs  the prefs said it was the default mail app so
I unchecked the pref and clicked OK  then it crashed.
     (5811369)	URL: www.tucows.com
     (5811369)	Comments: Asked if I wanted Mozilla to be the default mail handler.  I said
yes and it GPFd (Again).  I'll try the current build.
     (5811299)	URL: www.tucows.com
     (5811299)	Comments: Mozilla asked if I wanted it to be the default email program  I
said yes.  It GPFd
     (5771598)	URL: mapi32.dll replacement
     (5684282)	Comments: Opened mailer - clicked "yes" on the question about making this
the default mailer - program crashed.

Comment 5

[Jay Patel [:jay]]

Seth:  Not sure if the right component is set, so please change it and reassign
if needed...thanks!

Comment 6

[Shiva Thirumazhusai]

I am sorry I was changing the product and component two times.

On the first look the problem seemed to be in XPCOM.  There is no line number
348 in nsLocalFileCommon.cpp. So, it seems to be wrong. This may be another
sideeffect of gmake build.( nsLocalFile::InitWithPath
[nsLocalFileCommon.cpp  line 348])

But, the problem seems to be happening in this file one level up in the stack.
  nsMapiRegistryUtils::CopyMozMapiToWinSysDir
[nsMapiRegistryUtils.cpp  line 384]

Here is the parameters and local variables when this function is called.

nsMapiRegistryUtils::CopyMozMapiToWinSysDir   
  this = Register variable - data not available  
  buffer = "INDOWS\SYSTEM" 
  buffer[0] = I (73 0x49) buffer[1] = N (78 0x4e) buffer[2] = D (68 0x44) 
  buffer[3] = O (79 0x4f) buffer[4] = W (87 0x57) buffer[5] = S (83 0x53)          
  buffer[6] = \ (92 0x5c) buffer[7] = S (83 0x53) buffer[8] = Y (89 0x59)
  buffer[9] = S (83 0x53) buffer[10] = T (84 0x54) buffer[11] = E (69 0x45)    
            
  buffer[12] = M (77 0x4d) buffer[13] = . (0 0x00) buffer[14] = . (0 0x00)     
     buffer[15] = . (0 0x00)           buffer[16] = . (0 0x00)          
buffer[17] = . (0 0x00)           buffer[18] = . (0 0x00) 
 buffer[19] = . (0 0x00) 

 ... rest of them are 0x00
  buffer[258] = . (0 0x00) buffer[259] = . (0 0x00)  


 bExist = 0 (0x00000000)
 pMozMapiFile = {nsCOMPtr<nsIFile>}
 directoryService = {nsCOMPtr<nsIProperties>}
 rv = 0 (0x00000000)
 filePath = {nsCAutoString}
 mBuffer = "INDOWS\SYSTEM\Mapi32_moz_bak.dll" 
 mBuffer[0] = I (73 0x49)              mBuffer[1] = N (78 0x4e)              
 mBuffer[2] = D (68 0x44)              mBuffer[3] = O (79 0x4f)                
 mBuffer[4] = W (87 0x57)              mBuffer[5] = S (83 0x53)              
 mBuffer[6] = \ (92 0x5c)              mBuffer[7] = S (83 0x53)              
 mBuffer[8] = Y (89 0x59)              mBuffer[9] = S (83 0x53)               
 mBuffer[10] = T (84 0x54)              mBuffer[11] = E (69 0x45)              
 mBuffer[12] = M (77 0x4d)              mBuffer[13] = \ (92 0x5c)              
 mBuffer[14] = M (77 0x4d)              mBuffer[15] = a (97 0x61)               
 mBuffer[16] = p (112 0x70)              mBuffer[17] = i (105 0x69)              
 mBuffer[18] = 3 (51 0x33)              mBuffer[19] = 2 (50 0x32)              
 mBuffer[20] = _ (95 0x5f)              mBuffer[21] = m (109 0x6d)              
 mBuffer[22] = o (111 0x6f)              mBuffer[23] = z (122 0x7a)              
 mBuffer[24] = _ (95 0x5f)              mBuffer[25] = b (98 0x62)              
 mBuffer[26] = a (97 0x61)              mBuffer[27] = k (107 0x6b)              
 mBuffer[28] = . (46 0x2e)              mBuffer[29] = d (100 0x64)              
 mBuffer[30] = l (108 0x6c)              mBuffer[31] = l (108 0x6c)              
 mBuffer[32] = . (0 0x00)              mBuffer[33] = . (0 0x00)              
... rest of them are 0x00 ...
 mBuffer[62] = . (0 0x00)              mBuffer[63] = . (0 0x00)        
 pCurrentMapiFile = {nsCOMPtr<nsILocalFile>}
 fileName = {nsDependentCString} 
 mHandle = {nsConstBufferHandle<char>}
 mDataStart = 0x608f9290
    (*mDataStart) = Data not available 
 mDataEnd = 0x00000000 
    (*mDataEnd) = Data not available 
 fullFilePath = {nsCAutoString}               
 mBuffer = ""    
      mBuffer[0] = . (0 0x00)          mBuffer[1] = . (0 0x00) 
      mBuffer[2] = . (0 0x00)          mBuffer[58] = . (0 0x00)  
... rest of them are null ...
      mBuffer[59] = . (0 0x00)         mBuffer[60] = . (136 0x88)     
      mBuffer[61] = . (217 0xd9)       mBuffer[62] = . (231 0xe7)                
      mBuffer[63] = ` (96 0x60)

Comment 7

[Srilatha Moturi]

ccing Rajiv, changing QA to trix.
I am looking into this. 
> mBuffer = "INDOWS\SYSTEM\Mapi32_moz_bak.dll" 
looking at  the stack somehow 'W' and the drive letter are missing. 
Since when is this a top crasher? From the bug report I see that this is 
happening in windows 98. Does this happen on NT or 2k?

Comment 8

[greer]

Srilatha,
Here's a breakdown of platform info of the 32 current crashes on the Trunk.

cc'ing beppe. Since it shows (at the bottom) that she has crashed this one 
twice with builds in the past few days. Beth, can you reproduce this one?

Trunk (nsLocalFile::InitWithPath):       32
Count (Build)     Platform
   4 (2002050608) Windows NT  5.0 build 2195
   4 (2002050104) Windows NT  5.0 build 2195
   4 (2002042908) Windows 98  4.10 build 67766446
   3 (2002050705) Windows 98  4.10 build 67766446
   3 (2002042908) Windows NT  5.0 build 2195
   3 (2002042808) Windows 98  4.10 build 67766446
   2 (2002050708) Windows 98  4.10 build 67766446
   2 (2002050308) Windows 98  4.10 build 67766446
   2 (2002050108) Windows 98  4.10 build 67766446
   1 (2002050708) Windows NT  5.1 build 2600
   1 (2002050608) Windows 98  4.90 build 73010104
   1 (2002050608) Windows 98  4.10 build 67766222
   1 (2002042908) Windows NT  4.0 build 1381
   1 (2002042808) Windows 98  4.10 build 67766222

(6036047) Build: 2002050705 Plat: Windows 98  4.10 build 67766446 Time: 
2002-05-07 [e-mail]    crashed just starting up
(6036111) Build: 2002050705 Plat: Windows 98  4.10 build 67766446 Time: 
2002-05-07 [e-mail]    crashed when selecting to nscp7 as my default 
mail tool
(6070917) Build: 2002050705 Plat: Windows 98  4.10 build 67766446 Time: 
2002-05-08 [e-mail]

Comment 9

[Srilatha Moturi]

I am not able to reproduce this problem in my debug build on WinNT. Does anyone 
see this in a debug build? 

Comment 10

[rubydoo123]

I can repro this crash at will, I am on win98 using the NSSetupB.exe install
from 20020508 and 20020509

Comment 11

[greer]

Reproducible hence -> topcrash+. 
"Beth, can you run that through a debugger?" he asked with eager anticipation.

Comment 12

[rubydoo123]

I'll give it a shot!

Comment 13

[rubydoo123]

how do I undo making our app the default mail tool? I am on a different machine
for debugging purposes and had previously made our app the default and can't
find where to undo that.

Comment 14

[Rajiv Dayal]

You can undo by unchecking the same pref. Or better, to avoid any crash issues
etc, just start IE and make it the default mail application. Then when you go to
the Mozilla/Netscape pref it should be unchecked.

Comment 15

[Rajiv Dayal]

I am sorry above i meant Outlook and not IE.

Comment 16

[Srilatha Moturi]

For that matter you can also set Communicator 4.x to be the default so that the 
preference in question will be unchecked.

Comment 17

[rubydoo123]

Ok, so I went to 4.x, brought up mail and I wasn't even given the dialog to make 
it my default. I don't have Outlook. Can someone point me to the file where the 
pref is set so I can change it -- I do not see a pref settings anywhere on the 
pref panel

Comment 18

[rubydoo123]

ok, I set up Outlook, made it my defualt mail tool, came back to the build and I
am not given the dialog in our app. I need to do some moring poking around.

Comment 19

[Rajiv Dayal]

To make sure that Outlook is now your default can u please do a SentTo from
Windows Explorer or Word or any MAPI client app ? Then can u go from the browser
to 'Edit/Preferences/Mail and Newsgroups category and see whether the checkbox
for "Use Netscape Mail as the default mail application" is set or not set ?

Also just to clarify the dialog to make us the default mail application is
thrown up only when u bring up Mail.

Comment 20

[Rajiv Dayal]

When I try on my machine the nightly release builds (for last 3 days) i see that
the pref is disabled !! When i use the debug build it works fine. Looking at the
stack trash seems like some memory overwrite issue and maybe using the debugger
might not reproduce it.

I am doing a release build to figure out whats going on. Does any one see 1.0
branch release builds crash too, for me it doesnt. The mapi code at this moment
for both branch and the trunk is same so looks like we will have to also venture
around besides just looking at the mapi code.

Comment 21

[Rajiv Dayal]

Looking into this one, talked to Srilatha, reassigning to myself.

Comment 22

[Rajiv Dayal]

So I did a optimized/release build using the tree i had from last Thu-Fri and
when i tested using it, everything worked fine. Then I tested using the nightly
release builds for 20020502 and 20020503 and i saw the same problem, the pref is
disabled !! So if I do the builds it works fine and if i use the nightly release
builds it doesnt !! 

I went and checked the messenger.jar to see if the xul and js files for this
MAPI related pref is fine and it is. However, i saw that the MAPI component
itself (msgmapi.dll) does not exist for the nightly release builds !!!!!

No wonder it is grayed out and I am sure for the people seeing the crash it is
because they have some other copy of msgmapi.dll in their path which is getting
loaded. This could happen for people who did an upgrade, till yesterday an
upgrade didnot delete the older version of msgmapi.dll which exists in the bin
dir and not the components dir. Curt has checked in an upgrade fix to remove
this older file i think only today.

Comment 23

[Rajiv Dayal]

Ok so this one Is a gmake issue. When we do nmake everything builds and works
fine and the msgMapi.dll is exported to bin\components dir. However if you do
gmake this dll is exported to the bin dir and not the bin\components dir. 

On branch the machine for nightly release builds uses nmake for win whereas for
trunk builds the machine for nightly release builds uses gmake and thus all's
well on the branch but not on the trunk.

I also talked to leaf and he saw that on his verification machine that the
msgMapi.dll exists in the 'bin' dir and not the 'bin\components' dir.

Comment 24

[Rajiv Dayal]

Attachment: Makefile.in changes to export the msgMapi.dll to the components dir

Comment 25

[Rajiv Dayal]

The above patch should fix the problem seen here.

Leaf, can u please review this patch. I have tested on a machine that uses gmake
for builds and observed that the msgMapi.dll is now getting exported to the
bin/components dir correctly with this fix. However, can u also please try on
your verification machine. thanks, - Rajiv.

Comment 26

[Shiva Thirumazhusai]

cc'ing curt to take care of installation part of it.

Comment 27

[Shiva Thirumazhusai]

Also cc'ing seawood for r=/sr= ?

Comment 28

[hacker formerly known as [e-mail]]

Comment on attachment 82992 [details] [diff] [review]
Makefile.in changes to export the msgMapi.dll to the components dir

r=cls

Comment 29

[Scott MacGregor]

Comment on attachment 82992 [details] [diff] [review]
Makefile.in changes to export the msgMapi.dll to the components dir

sr=mscott

Comment 30

[Rajiv Dayal]

fix checked in to the trunk.

Comment 31

[Trix Supremo]

verified using trunk build 2002052108