Closed Bug 100395 Opened 23 years ago Closed 22 years ago

Windows 2000 install / profile creation problems / running Mozilla fails (documents and settings/domain account)

Categories

(Core Graveyard :: Profile: BackEnd, defect)

Product:
Core Graveyard
Component:
Profile: BackEnd
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 162025
Milestone:
mozilla1.0.1

People

(Reporter: jimmi, Assigned: ccarlen)

References

Details

(Keywords: crash) 

Running Windows 2000 with multiple users, install of 0.9.4 is successful,
attempts to run Mozilla and Mail as Administrator are fine without requiring any
profile--this is good and fine--but attempts by users (both Power Users and
Users groups) to run Mozilla, Mail, and Profile Manager fail: for Mail and
Mozilla the process starts, you see the splash screen, then it promptly
terminates. In the Profile Manager you can enter data but clicking Finish etc
fail to create a profile ***UNTIL*** you specify a destination directory. I only
specified a directory for the profile of my own ownership as a Power User so I
haven't investigated this extensively but the problem that needs fixing is that
Mozilla and Mail and the Profile Manager need to create and/or use a default
profile (or initialize the creation of a profile) and then ****detect the
current user's directory for settings**** so that clicking finish will create
the default/user's profile instead of failing. In Win2k I believe this is
generally "C:\Documents and Settings\<username>\Application Data\" and for the
default user it is "C:\Documents and Settings\Default User\Application Data\".

Looking forward to the full release. Thank you for all of the hard work! -Jim
this problem persists even after creating profiles. running Mozilla does not 
work unless I: start the Profile Manager, create a profile, run Mozilla 
immediately following (re)creation of the profile.
We use the Win32 APIs to get the directory CSIDL_APPDATA. This gives us:
"C:\Documents and Settings\<username>\Application Data\" The question is why in
your case it is not.
No dupes found. Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I am in a multiuser environment with roaming desktops, preferences, etc. Could 
this simply be a problem with my $PATH (or something)? If you need more data 
please let me know, or if there is a flag that I can use to point to my profile 
using the explicit path to it, or a flag to disable use of profiles, please let 
me know--I'd like to use Mozilla without this extra step, at least until this 
bug is fixed.
QA Contact: ktrina → gbush
accepting
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
Doug, can you look at comment #2? I don't have a way to test this. Do you know
anything about it?
Target Milestone: mozilla0.9.8 → mozilla1.0.1
I've got similar problems with the account that I use the most.  I'm running a
Windows 2000 native domain with only a few members(<20).  I've tested with test
users with redirect (mydocs & apps) on and off.  The only account that doesn't
work is mine, it has local/machine admin access.  Could not reproduce with test
accounts under either power user or local admin access.  Tested on two systems
with the same results.  There seems to be something special in my account
affecting this, I don't know enough to find out what.

If you have a scenario you want me to test, email me and I'll see what I can do.
I am also experiencing this bug. We have a Win2K native domain (roaming 
profiles, etc) with 2000+ users. A handful of users experience this bug. It 
affects them on any machine - and others can be fine using the same machine. I 
have tried resetting someone's entire account (removing their profile and re-
generating a new one from the system default - the same default that generates 
working profiles on a regular basis), but this does not affect the symptoms. (I 
have also tried reinstalling moz in conjunction with this - versions 0.9.5 
0.9.6 and 0.9.7 all display this problem).

HTH

(And if you need more info, don't hesitate to ask ¦¬])
I am also experiencing this bug with RC2, on two separate XP Professional machines. 
Administratos can run mozilla fine. When run by a member of the Users group, Mozilla crashes soon 
after the splash screen is displayed; when run as a Power User, Mozilla shows the main window 
before copping out. Interestingly, if a Power User who has previously run mozilla is made into a 
User, mozilla manages to make it to the stage where it crashes as run by a Power User.

I sent some 
crash reports with the feedback agent, and have Visual Studio 7 installed if someone wants to tell 
me what do to get more detailed info (I only use ot for C# development, not C++ so can't do it all by 
myself).
Stack trace of my crash:

>	appcomps.dll!600888f8() 	
 	appcomps.dll!60088ea8() 	
 
	appcomps.dll!60088f21() 	
 	appcomps.dll!60089e71() 	
 	rdf.dll!60a89054() 	
 
	rdf.dll!60a896d0() 	
 	appcomps.dll!6008c6c0() 	
 	rdf.dll!60a84b6a() 	
 
	appcomps.dll!6008b72c() 	
 	appcomps.dll!6008b35c() 	
 	xpc3250.dll!60d3239c() 	
 
	xpc3250.dll!60d3591b() 	
 	js3250.dll!60e2a51f() 	
 	js3250.dll!60e2f5bf() 	
 
	js3250.dll!60e2a55c() 	
 	js3250.dll!60e2a7f6() 	
 	js3250.dll!60e1493a() 	
 
	jsdom.dll!606d3cb2() 	
 	jsdom.dll!606db6ea() 	
 	jsdom.dll!606dbb80() 	
 
	gkwidget.dll!6054a87b() 	
 	appshell.dll!600d71ca() 	
 	mozilla.exe!00401bd7() 	
 
	mozilla.exe!0040378d() 	
 	kernel32.dll!77e7eb69() 	

Perhaps not too useful but I 
don't know how to get the debugger to bring up the source yet. :)
Sam: It would be more helpful if you could provide a TalkBack ID. After the
crash, just run (<moz-dir>/bin/components/talkback.exe).

PS If you add a comment in a bug, it's helpful if you add yourself to the CC
list -- that way, you can receive any responses.
Ok then... incident IDs are TB6243023W, TB6241697Z, TB6241652M and TB6241623Q.
I wonder if this could be related to my bug #146246?
http://bugzilla.mozilla.org/show_bug.cgi?id=146246

In this bug I am crashing similar to the way described here, but after
installing RC2. I don't have a problem with RC1. Note that I am running as an
admin (as I am sole user) and am not using remote profiles.
*** Bug 150814 has been marked as a duplicate of this bug. ***
Keywords: crash
Summary: Windows 2000 install / profile creation problems / running Mozilla fails → Windows 2000 install / profile creation problems / running Mozilla fails (documents and settings/domain account)
jpatel and shiva, can you help dig out the talkback data for this problem?
Sam Morris:  Could you possibly reproduce this crash again with RC2 or any more
recent build and post your Talkback IDs?  Your old incidents are no longer in
our Talkback database...since it's been longer than 30 days.  I want to look at
the stacks you are getting through Talkback...so please try to reproduce this
again and let us know what the Talkback IDs are. Thanks!
I can no longer reproduce the crashes using 1.0 Release. Looks like it's been
fixed, at least running under XP.
Thanks for the quick reply Sam.  

Ok, so is anyone else still seeing this problem?  Jim, Jack, James or Dacheng?
If so, could you post your Talkback IDs?  If no one is crashing anymore, perhaps
this should be marked worksforme?
When I run mozilla on our Win2000 boxes, where the users profile directory is
mostly on the server as described on
http://www.isg.ee.ethz.ch/tools/realmen/det/skel.en.html I get no crash or
anything from mozilla. It just shows the splash and goes away. If I start the
profile manager I am able to launch mozilla, but the profile does not get saved.
I have not tested with the most recent builds, but with all the ones since 0.96
which I tested (that is when we got the system). I will try again tomorrow. 
Jay,

Talkback is not capturing anything.  

I had it running in the background and then run mozilla(with the usuall 
effect), nothing.  

I ran mozilla with the usual result, and then ran Talkback, nothing.  

With Talkback running in the background, I manually created a profile and 
successfully launched mozilla, nothing.  

Attempted to restart mozilla after shutting it down, nothing.

Sorry guys, am I doing something wrong?
Dacheng Tang:  Talkback is a feedback agent that is installed with Mozilla and
is triggered when you crash.  A window should pop up after a crash if you have
successfully installed a Mozilla build with Talkback.  You should not have to
run Talkback manually (talkback.exe in the components dir)...unless you just
want to find the recent incidents you have submitted.  Try installing Mozilla
again and choose the Custom option...in the Additional Components part of the
installation make sure Quality Feedback Agent is checked...that will ensure that
Talkback is installed.  If you have any questions, please email me.  Thanks.  
 Dacheng Tang reports exactly what is happening here ... to the point ... and it
happens consistanly over all mozilla and netscape (>=6) versions. On new
machines, old machines. As soon as the users profile is not local, see previous
comment.
Folks,

I just did a custom install of 1.1alpha with Talkback.  Talkback never gets 
triggered.  I think as far as Talkback is concerned, nothing happened.

This is a good one for all those Microxxxt conspiracy people.

Dacheng
as andrew hagen pointed out, Bug 110832 might be related.  has to do with
Mozilla being unable to hand UNC file paths
I'm a system Administrators on a Win2K network and this bug exist on my local 
XP Pro PC where the user (myself) is setup with an admin/domain profile. I 
installed the browser and have complete administrative rights to the network 
(domain) and the local PC, but for some reason Mozilla (1.0 or the beta) seems 
unable to create a profile while in the domain. After combing through the web 
site I did notice some discussions regarding Win2k's "folder redirection" (UNC 
Paths) and that others had profile issue's similar to my own when using this 
Win2k Server feature. For instance, my user profiles and application data are 
redirected to a network share (for backup purposes), and though I've tried to 
force Mozilla to use the network folder the app is unable to create a profile 
in the specified directory and hence will not open. I can create the profile 
locally but once the browser is shut down it can not re-initialize without 
having to recreate a new profile, and this is the crux of my problem. 

Strangely enough if I logon to my local PC as the domain or local admin the 
browser is fine, go figure. All I can guess is it is possibly a result 
of "folder redirection" in the domain, but at this time it would only be a 
stab in the dark. If you find something else let me know, like I said I 
support open source and want to use this browser if possible. 

Best regards,

Levi 
_____________________________________________________________
"It is not necessary to change. Survival is not mandatory." 
I have now disabled all the folder redirection I had set up in the domain. 
Everything in the profile is as it was originally - as local files / 
directories within c:\documents and settings\%USERNAME% on the disk, copied to 
and from a server at logoff/logon. The bug still exists in this environment, 
with version 1.0 which we are using at the moment. I am also unable to capture 
any talkback information at the moment.
I see this bug is marked as critical, but I see no changes ... I just verified,
we still see the same issue with all mozilla AND netscape builds currently
available ... 
I've been playing around with Pheonix 0.2.  So far it seems that Pheonix is 
also affected by the same problem.  Could anyone verify this?  If so, is there 
any information we can derive from this besides that they share buggy code.  I 
don't know enough to go through the code myself.

Dacheng
Is anybody at Mozilla.Org/Netscape actually understanding the
implications of this bug ? As long as it exists,
Mozilla/Netscape/Phoenix

  ********  DO JUST NOT WORK ***********

in a reasonably corporate windows 2000+ environment. This is
market-share you are loosing  ...
Yep, that's the problem - it's the issue with c:\. This even happens under XP (I
personally have my installation on d:\ and have this issue as well).

*** This bug has been marked as a duplicate of 162025 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
verified duplicate
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.