Closed Bug 53952 Opened 24 years ago Closed 23 years ago

Mozilla won't start if another Windows DDE app is frozen or blocking DDE requests

Categories

(SeaMonkey :: UI Design, defect, P1)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: jruderman, Assigned: law)

References

Details

(Keywords: hang, Whiteboard: fix in hand)

Attachments

(3 files)

Steps to reproduce:
1. Open an IE window
2. Move IE window out of the way so you can click your desktop shortcut to Moz
3. Type ftp://ftp.mozilla.org:15311 in IE location bar
4. Quickly open Moz

Result: Mozilla waits until IE thaws before displaying the splash screen.

Expected result: Mozilla opens quickly so I can ditch IE and actually get to 
the ftp site.


Additional notes: 

IE is not using 100% cpu while trying to connect to the ftp site.

With the -console option, Mozilla freezes after the first two lines (stdout, 
stderr redirected to console).  The console window itself also freezes -- I 
can't click the 'x' at the top to get the normal Windows warning that I'm about 
to kill a DOS app.


Additional freezes that prevent Mozilla from loading:

- ie:
about:<script>while(1);</script> and answer "yes" to the 2-second dialog 
(you'll get another one in 10 seconds)

- mirc 5.7 or 5.8:
;put this in "remotes" and then type /freezeme
alias freezeme {
while (1){
}
}

- telnet.exe or putty.exe
connect to www.mozilla.org on some random 4-digit port
I have seen this happen, and initially I would say that it's a problem with
Win9x's multitasking model.     But the fact that it happens with Mozilla, but
not with lots of other programs makes me wonder. . .
Bill, any idea what's going on here?
Assignee: don → law
I've seen this behavior and now I'm starting to think I know what's happening.

If Mozilla is already running, launching another instance will attempt to locate
the running instance by finding a DDE server (this done by doing a DDEConnect).
 What I've observed is what is described here: the win32 API request blocks in
some cases (I've seen it block forever, for all intents and purposes).  I never
could explain this (and only saw it on certain machines).

With the information provided here, it appears as if the Win32 DDE requests
block until DDE-aware processes respond.

I suspect we will have to find a way to detect an already-running instance of
Mozilla that isn't subject to this problem.  That shouldn't be too hard.
Status: NEW → ASSIGNED
*** Bug 56897 has been marked as a duplicate of this bug. ***
This might have been causing bug 42997 (mozilla wouldn't start with 
old/corrupted versions of outlook 2000 running).
also 100% repro on NT (Windows 2000):
Mozilla won't start when you have hit a breakpoint in a Visual Studio debugging
session
when you hit F5 in VS to resume the program being debugged (just any program,
not Mozilla of course)
then Mozilla will start

I just saw this on Windows 2000 and looked around a little. I found this on 
Internet:

"Does your program create windows or use a standard message loop? If so make
sure that you're not doing a WaitForSingleObject or WaitForMultipleObjects
call in those threads - use MsgWaitForMultipleObjects instead.

The reason for this is that DDE calls SendMessage to send messages to all
windows in the system (using something like a "while (gotNextWindow)" loop)
and if a thread that owns a window is in a wait and takes no notice of the
message, the DDE subsystem (or at least that application) can deadlock.

Look at the notes at the end of the help topic for WaitForSingleObject if
you need more info. Hope this helps.

Regards,

John Bates        mailto:jlb@powerup.com.au
Lead Developer
JLB Productions     http://www.devstuff.com"

Also http://support.microsoft.com/support/kb/articles/Q136/2/18.asp describes a 
bug in Windows 95 that could cause this, but that is only in Windows 95.

I also got an interesting search hit: 
http://www.angelfire.com/biz/rhaminisys/ddeinfo.html but it won't load right 
now for me.
nav triage team:

Sounds like we should fix this one. Marking nsbeta1, mozilla0.9
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9
Adding CC
looks like windows98 blocks on certain Win32 calls if other application is frozen. 
Target Milestone: mozilla0.9 → Future
This isn't just Win98.  It also happens on Win2000.

Can someone change the summary to win32 instead of win98 and put other win32
OS's in the os list?  I'm not sure I am allowed to change these feilds...
I saw this today with w2k.
Mozilla doesn´t start and I deleted all (Mozilla, Profile, Mozregistry.dat) and
reinstalled Mozilla :-(
After that I saw, that I have a dead Acdsee process (taskmanager).
After I killed this process, mozilla started again. 
Changed summary (there doesn't seem to be a way to set the OS field to "all
Win32 OSs").

The problem is described completely by the MS knowledge-base article (previously
cited): http://support.microsoft.com/support/kb/articles/q136/2/18.asp.
Previously, it was stated that this was a Win95-only problem but I don't think
that's the case.  NT 3.51 is mentioned explicitly and I suspect that subsequent
MS OS versions (Win98, WinME, and Win2K) also suffer from the same problem.

There is no ready fix, because the problem is with the other applications.  The
only thing we could do is find an alternative to use of DDEML (note that we
don't do our own WaitFor...Object calls).

I don't think we have resources to do an alternative DDE implementation using
the lower-level DDE apis/msgs.  We could do some other form of IPC but support
for DDE to enable third-party app interaction was a goal.  But since we don't
really support that, maybe abandoning DDE entirely would be best for the short term?

Anybody should feel free to contribute solutions.
Summary: Mozilla won't start if another win98 app is frozen → Mozilla won't start if another Windows app is frozen
could we ask the os if there are any known dead apps, and disable dde while we 
know they exist?
This bug might be related to bug 50424, "Run moz while moz is already running 
--> nothing happens".
*** Bug 66161 has been marked as a duplicate of this bug. ***
Mozilla as a DDE Server ? why not

The problem is that DDE is used for by mozilla itself to communicate
with other mozilla instances to ensure that there is always only one instance
running. The command line (C string) is sent to the previous instance wich takes
the focus.

Maybe a simple solution would look like:

1) Create a hidden window with a known Window class (there is already a Phantom
dialog created then destroyed)
2) When a new mozilla instance starts try to find a window of that class
3) If found send a WM_COPYDATA (see MSDN "Using WM_COPYDATA for IPC") to that
window with the commandline then exit
4) If not found proceed normally

Of course the WM_COPYDATA handler must be written but it should not be difficult





a solution would be to use WM_COPYDATA message as IPC mechanism


We'd like to support DDE for the benefit of third-party apps, as I mentioned
earlier.  But using a hidden window is a good plan if we drop DDE support entirely.
*** Bug 67069 has been marked as a duplicate of this bug. ***
*** Bug 70973 has been marked as a duplicate of this bug. ***
Target Milestone: Future → ---
This bug sucks.

I've come up with a plan, though (looking at bug 70973 prompted me to think
about this).

I think the trick is to make the support for DDE optional.  Basically, we use
messages via a hidden window as the standard mozilla<->mozilla ipc mechanism.
We will also provide an optional DDE server for third party apps to use.

The user will be able to turn off the DDE server (via some "-nodde" cmd line
switch).  That's for "power users."  An alternative is to only start the DDE
server if the user specifies some "-dde" flag (or by some registry key which
would enable 3rd party applications that rely on DDE communication with Mozilla
to turn it on).

We will monitor our use of DDEConnect and if it fails (determined by storing
info in the registry?) then we'll not try next time.

The least risky strategy would be to abandon the DDE server support, switch to
some alternative IPC, and then re-enable the DDE server as time/resources
permit.  Basically, that puts priority on making startup more reliable and
lowers the priority of the DDE support.

Another approach might be to run the DDE server on a separate thread.  That way,
if that thread blocks, life goes on.

I'm resetting target milestone to renominate this.  Note to triagers: This is
important!  The failure is fatal!

If anybody can identify specific applications that block Mozilla from starting
due to this problem, please post those here.  That will help us prioritize things.
what is the cost of moving DDE to some other thread?

unfortunately, it's really hard to tell if our DirectX/Sound bugs are really 
this.  a search for windows* + keyword:hang should turn up the bugs ...

I think we have some dde test apps somewhere, but currently, we have no real 
standard way of diagnosing the problem, if we could create such a diagnostic 
the problems would be much easier to identify.
Keywords: hang
Moving DDE server to another thread isn't too much trouble *if* we set up the
alternate ipc mechanism (that thread would simply convert the incoming DDE
request and use that alternate mechanism).

As for diagnosing: A hang prior to splash screen is always this problem.  If you
dynamically attached the debugger and broke into the app, the call to DDEConnect
would always be there.
I use the Microsoft Network, and I see this bug when the MSN dialer (MSN 
Explorer) is open and connected to the Internet.
adding to cc
Bill Law wrote on http://www.mozilla.org/status/2001-03-21.html :
> I have a non-DDE ipc mechanism working. 

Maybe bug 68702 "[RFE] Implement inter-process communication (IPC) in Mozilla"
(mozilla1.0, patch, review) is somehow related, maybe not. I'm not familiar with
any of these issues, I just stumbled over the "IPC" acronym in both bugs.
That "IPC" isn't of use here.  This stuff needs to happen before Mozilla loads
and starts up all it's services.  I think a mechanism built on top of Necko is
too heavyweight.
This is a really bad bug because the only recourse for the user is to give up 
on Mozilla.  Nominating as "cat food."
Keywords: nsCatFood
This also happens for me on Windows 2000 (and did NT 4.0). 

I happens 100% of the time when I run certain java apps (JServ/tomcat + some of
my own servers). If I quit the java apps when mozilla is blocked it will start
perfectly. It happens with some other apps too... 

This is a very annoying problem. (possibly related: bug 65197)
*** Bug 65941 has been marked as a duplicate of this bug. ***
How about this for a workaround:

Start a thread whose job it is to call DdeConnect.

Wait 15 seconds for the thread to terminate. If it doesn't, kill it.

Of course, you could just use WM_DDE* messages :-)
nav triage team:

Marking nsbeta1+, nsCatFood+, mozilla0.9.1
Target Milestone: --- → mozilla0.9.1
I frequently hang on startup before the splash under Windows/ME. I can't find 
the app that is causing it to hang, but it always works as soon as I reboot, but 
no longer starts up after a while. The only workaround is to reboot - closing 
applications manually does not help. Do you think this problem is related? There 
are a few other "hang on startup before splash" on windows/98/ME under other 
specific conditions (after loading Windows Media Player, on low memory 
conditions, reports of Direct/X interactions, etc). Are you saying these are all 
related to DDE?
I think we're saying that most of them are dde related, but some are not.  I 
suspect that some of the media ones could actually be related to locked 
devices, but I could be wrong and have not tried to test this theory.

Law: why don't we use a Semaphore, if we successfully create one then we don't 
try to contact a mozilla session, if we fail, there's already one in existance.

IIRC this was the standard way to handle the problem on win32

The CreateSemaphore function creates a named or unnamed semaphore object. 
#include <winbase.h> //requires win32, not supported by win32s
HANDLE CreateSemaphore(
NULL, /*LPSECURITY_ATTRIBUTES pointer to security attributes*/
LONG(0), /*initial count*/
LONG(1), /*maximum count*/
"mozillaGeckoV..." /*LPCTSTR pointer to semaphore-object name*/  
);
/*
Return Values

If the function succeeds, the return value is a handle to the semaphore object. 
If the named semaphore object existed before the function call, the 
GetLastError function returns ERROR_ALREADY_EXISTS. Otherwise, GetLastError 
returns zero. 
*/
Summary: Mozilla won't start if another Windows app is frozen → Mozilla won't start if another Windows DDE app is frozen
I presume they're all DDE problems.

I have a patch that uses a non-DDE technique to communicate with the running
Mozilla.  I'll try to attach that shortly (it isn't done) and then people might
be able to test whether this fixes their situation.

timeless: The semaphore works to tell if Mozilla is running, but in order to
talk DDE, you still have to do a DDEConnect.  So we need to alternative IPC
mechanism in place, as well.
true, but this bug is theoretically limited to the summary [frozen dde using 
win32 apps], so the semaphore should solve problems when mozilla isn't running, 
at least for the beginning, right?
as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from 
mozilla0.9.1 to mozilla0.9.2. 
Target Milestone: mozilla0.9.1 → mozilla0.9.2
law:

To me the problem is that mozilla is at the same time a DDE client *and* a DDE
Server. The DDE Client part needs DDEConnect() and I think that the DDE Server
part doesn't need that (correct me If I'm wrong but I think that
DdeNameService() is enough)

The DDE Server part is used by the first Mozilla instance to register the DDE
service. Mozilla is a DDE Client because it needs to talk to other Mozilla
instances to transfer control to the first instance (the server)

The DDE Client code in Mozilla needs to be removed and replaced by some private
communication process but the DDE Server registration is still needed (and it
must be done only once when the first instance is started)

The result will be that mozilla will not block *itself* anymore but
3rd party applications that use some DDE client code (DDEConnect() call) will
still block but it seems to be a well-kown DDE problem ...

Cool; this is a great tip.  Coupling this with my already-coded patch to use 
WM_COPYDATA to a dummy ("message") window will solve the problem, then.  I was 
thinking I was going to have to do the DDE server on another thread to avoid 
the DDEConnect hang.  But you are right; if we can detect client vs. server 
mode (and communicate from client to server) via another means, then Mozilla 
does not need to ever do a DDEConnect.  Problem solved.

When I get back to this, it should be relatively easy to code this up and solve 
this problem once and for all.  I'll try to remember to attach the patch that 
I've got so far as soon as I can track it down.
There are lots of different and very simplyeways to handle the first instance - 
later instance thing in a couple of code lines and without resorting to DDE, eg:

1) use a Property (parented to the desktop window) or Atom. On startup, the app 
just checks whether something of the appropriate name exists. If not, it 
registers it.

2) Use a named object, such as a mutex (same procedure as above)

In either case a 'token' (eg. window handle) of the first instance can be found 
for the purpose of passing the invokation of a further instance to the original 
instance. Also WM_COPYDATA might be overkill for the latter (I have had all 
sorts of cross-Windows-platform issues arising in the past by using this), and 
its "1-way IPC" - it doesnt allow the receiver to return a result to the sender 
(eg. if new instance cant be done, for some reason). There are other messages 
which will automatically convert the LPARAM to have visibility to the receiving 
process, assuming it points to a string.

Of course this just refers to start-up issues. For Mozilla to expose automation 
functionality for other apps/scripts to use, either object model exposure (nice 
for automation through scripting) or standard IPC are far better, being 
divorced from the windowing aspect of things (unlike DDE).

DDE was a great way to do IPC back in the days when it was all that there was 
(Windows 2.0, if I remember correctly) but I personally avoid it like the 
plague these days :-)

In the other hand I'm very much a Mozilla newbie, so I might be talking 
b*ll*cks :-)

Cheers,
Chris

PS - Note that I assume that Mac/Linux have similar constructs to the above 
(which use Windows terminology).




 
Forgot to mention - I just finished by first Mozilla build (0.8.1) and it wont 
run - it just dissapears into the task list without doing anything visible. I'm 
using NT4/SP6.  As far as I know I dont have any resource (memory/disk/CPU) 
problems and nothing is locked up on my system  - task manager thinks 
everything is running OK, and the MS Spy++ utility (which tends to hang if you 
run it when something has a blocked message loop) runs OK.

Cheers,
Chris
*** Bug 69929 has been marked as a duplicate of this bug. ***
Blocks: 68680
No longer blocks: 68680
*** Bug 68680 has been marked as a duplicate of this bug. ***
From bug 68680:

Ontrack's SystemSuite 3.0 Task Manager is another bad mozilla-blocking app.
*** Bug 65197 has been marked as a duplicate of this bug. ***
From bug 65197, this happens with Apache+PHP module as well.
This bug has now oficially 8 dups. If you add bug 73542, a dup of duplicate bug
66161, this makes 9. From the discussion, it seems there may be other dups still
at large. Isn't it tme for marking it mostfreq?
Keywords: mostfreq
*** Bug 70799 has been marked as a duplicate of this bug. ***
> Ontrack's SystemSuite 3.0 Task Manager is another bad mozilla-blocking app.

This seems to block Netscape 4.7 as well, but it doesn't block any other 
application software I've tried.
Whoops - forgot to add. If you start Moz/Netscape with the SystemSuite 3.0 "Task 
Manager" service running, it wont appear (except in the task list). However if 
you then use the control panel to stop this service, it will complete its 
initialisation and appear. Maybe thats a clue as to what is going on.
*** Bug 78347 has been marked as a duplicate of this bug. ***
*** Bug 76043 has been marked as a duplicate of this bug. ***
*** Bug 69220 has been marked as a duplicate of this bug. ***
*** Bug 74295 has been marked as a duplicate of this bug. ***
*** Bug 77836 has been marked as a duplicate of this bug. ***
I've applied the patch and it works for me, good job :-)

I mean that I only have one mozilla.exe when I try to run it twice
and that it doesn't block anymore (for me it was with Visual Studio see above)

However I played around with mozilla and DDESpy and I can see that
the server is never unregistered (ie run mozilla, close mozilla, run mozilla
again, and you can see *2* DDE servers registered instead of *1*)

I think that this is because a DDENameService(..., DNS_UNREGISTER) in
nsNativeAppSupportWin::Quit() method call must match the DDENameService(...,
DNS_REGISTER)


Blocks: 65305
nav triage team:

Since we have a fix, moving up from mozilla0.9.2 to mozilla0.9.1
Target Milestone: mozilla0.9.2 → mozilla0.9.1
Sorry to just rush into this with a potentially lame suggestion, but if I 
understand correctly, you are acting as a DDE client to detect if another 
instance of Mozilla is running. Why not just try to create a named mutex 
called "MozillaRunsMutex" or something similar, and if it succeeds but 
GetLastError returns ERROR_ALREADY_EXISTS, then you know that you already have 
another Mozilla running. Upon exit, you might want to close the handle returned 
by CreateMutex, but if you don't, Win32 will clean it up for you anyway.

Marton Anka
marton@03am.com
marton@03am.com: please read the patch. We will no longer act as a dde client.
Keywords: approval, review
*** Bug 79269 has been marked as a duplicate of this bug. ***
Thank you Marton.  We welcome all suggestions, lame or not :-).

Your suggestion was made previously.  I noted then that a semaphore isn't
sufficient, because in addition to detecting whether Mozilla is running, we also
need to be able to communicate with that running instance.  A semaphore alone
isn't capable of that.

The current scheme (in the patch) satisfies both requirements, hopefully in a
way that doesn't hang.
How does the patch work if you were to run both Mozilla and a NS 6.x commercial 
build at the same time?  Do they have different DDE application names?
*** Bug 65305 has been marked as a duplicate of this bug. ***
Making this P1 since bug 65305 (which was P1) was closed as a dup.
Priority: P3 → P1
Whiteboard: fix in hand
I added the call to DdeNameService(...DNS_UNREGISTER), as suggested.  I also 
had to add code to nsAppShellService so that it would make the right call at 
Quit() time to cause this code to be executed.

Looking for review and super-review.
re: Mozilla vs. NS 6.x

Mozilla and Netscape do have distinct DDE appliation names.  The patch preserves
that distinction by varying the "message window" class name accordingly.
Blocks: 75599
Bill,
the code itself looks fine, but your deep-nested if statements are very hard to
follow. Can we just do some early-returns when errors are encountered? Also,
you're making extensive use of printf() when we have stuff like NS_WARNING()
available to you (i.e. for debug-only stuff)

for example, in MessageWindow::Create(), you have:

+        if ( winClass ) {
+            // Create the window.
+            mHandle = ::CreateWindow( className(),
+                                      0,          // title
+                                      WS_CAPTION, // style
+                                      0,0,0,0,    // x, y, cx, cy
+                                      0,          // parent
+                                      0,          // menu
+                                      0,          // instance
+                                      0 );        // create struct
+            if ( mHandle ) {
+                #ifdef MOZ_DEBUG_DDE
+                printf( "Message window = 0x%08X\n", (int)mHandle );
+                #endif
+            } else {
+                printf( "CreateWindow failed, reason=0x%08X\n",
(int)::GetLastError() );
+                rv = NS_ERROR_FAILURE;
+            }
+        } else {
+            printf( "RegisterClass failed, reason=0x%08X\n",
(int)::GetLastError() );
+            rv = NS_ERROR_FAILURE;
+        }
+        return rv;
+    }

This could be shortened to:

if (!winClass) {
  NS_WARNING("Registerclass failed");
  return NS_ERROR_FAILURE;
}

mHandle = ::CreateWindow( className(),
                                    0,          // title
                                    WS_CAPTION, // style
                                    0,0,0,0,    // x, y, cx, cy
                                    0,          // parent
                                    0,          // menu
                                    0,          // instance
                                    0 );        // create struct

if (!mHandle) {
    NS_WARNING("CreateWindow failed");
    return NS_ERROR_FAILURE;
}

#ifdef MOZ_DEBUG_DDE
    printf("Message window = 0x%08X\n", (int)mHandle );
#endif

return NS_OK;

---

The flow of control is much more obvious, and error checking doesn't change the
indentation of code.

You might also like NS_ENSURE_TRUE, which will throw an assertion (so you can
debug it), and return automatically:

mHandle = ::CreateWindow( className(),
                          0, // title
                          WS_CAPTION, // style
                          0,0,0,0, // x, y, cx, cy
                          0, // parent
                          0, // menu
                          0, // instance
                          0 ); // create struct

NS_ENSURE_TRUE(mHandle, NS_ERROR_FAILURE);

// mHandle garanteed to be non-null after this..
Thanks, Alec.

In this updated patch, I've now adopted liberal use of NS_ENSURE_TRUE, which 
best matches the intent and semantics of the previous printfs.  The only thing 
missing is the ::GetLastError calls.  But I'll just add those back in if I ever 
have to debug this code again.  Maybe we need a vararg version of NS_WARNING...

I'm still trying to forget everything I learned while growing up about 
structured programming and C++; please bear with me :-).  The updated version 
is more succinct, tho'.
great, looks generally good, though I still don't understand why you use this
pattern:

NS_ENSURE_TRUE(val = SomeCallWithLotsOfParams(a, b, c, d, e), NS_ERROR_FAILURE);

instead of 
val = SomeCallWithLotsOfParams(a, b, c, d, e);
NS_ENSURE_TRUE(val, NS_ERROR_FAILURE);

from my perspective the 2nd one is much easier to read, and any decent compiler
will generate the same compiled code for both versions...

a varargs NS_WARNING sure would be nice..hard to do with macros though.

By the way, this isn't non-structured programming, this is simply a matter of
seperating out error handling from the logic of the code.

I won't let that style nit block this sr=, but I would prefer the latter form.
sr=alecf
I don't think a compiler will generate exactly the same code (unless it's a
*really* smart compiler).  I was wanting to put the "SomeCallWithLotsOfParms"
inside the macro so the alert would be more informative and approximate what the
printfs did.  Otherwise, it just says "val" with no clue about why.

It is hard for an outsider to tell from the discussion when a bug fix is
supposed to show up in the nightly build, so I'll just note here for the
infomation of Mozilla maintainers, that as of the 2001051220 nightly build,
[which is now part of the 0.9.0 effort, I suppose], when StarLogo 1.2 is running
(not hung, just running at all), Mozilla blocks at launch before the splash
panel is displayed, and, however much later, finishes its launch when the
StarLogo app is exited.  This is described in bug 74295, which I reopened
earlier as it seems not to be an exact duplicate of what is being described
here, which latter seems to focus on other apps which are misbehaving, though
that may be merely my lack of understanding.
*** Bug 74295 has been marked as a duplicate of this bug. ***
+// Start: Tries to find the "message window" to determine if it
can you make that a /* comment?

bad indent:
+       retval = LoadString( (HINSTANCE) NULL, id, (LPTSTR) nameBuffer, 
sizeof(nameBuffer) );
+    if ( retval == 0 ) {

r=timeless, let's get this in.  We need get people testing it.  If you don't 
want to have this in on the trunk yet, could we please spin a test build and 
stick it on ftp.mozilla.org so people who have seen bugs which we claim are 
this can test it?
Summary: Mozilla won't start if another Windows DDE app is frozen → Mozilla won't start if another Windows DDE app is frozen or blocking DDE requests
*** Bug 80585 has been marked as a duplicate of this bug. ***
I have personally experienced undesireable DDE behavior on Win98.  For Acrobat 
5, I had to put some workarounds for this unexpected behavior.  For example,
if you start Windows Media player on Win98 and make a DDE call, your
application will hang. Now we have code that says "if you are on
Win98 and Windows Media player is running, try not to use DDE.  If you
must use DDE, then tell the user to exit windows media player before
proceeding."    
Wow. do you have a list of applications or is WMP alone? And has anyone 
considered complaining to microsoft?
Another data point - ActiveState's Komodo, and Python itself also has this 
problem.  We have had reports that running mysql or SQL Server on the same 
machine can cause the same problem - these apps are not processing a message 
queue, and can cause Mozilla to refuse to start.

The "correct" solution appears to be to drop the DDEML libraries that Mozilla 
(and many many other apps) use, and instead roll your own using 
SendMessageTimeout.
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I confirm this fix has repaired the problem reported in bug 74295; Mozilla now
launches successfully with a Starlogo 1.2 for Java project running.  Thanks!
Apache with PHP module and Mozilla builds with the fix also run together 
perfectly now. TUVM!
My issue with an unknown DDE server blocking Mozilla's startup has also been 
resolved.  Much appreciated!  Now I don't have to reboot my computer before 
trying to start Mozilla.
*** Bug 81411 has been marked as a duplicate of this bug. ***
*** Bug 79754 has been marked as a duplicate of this bug. ***
*** Bug 76432 has been marked as a duplicate of this bug. ***
Veryfying on my own (very positive) experience since the check-in and all the
other comments. Good job. Thanks!
Status: RESOLVED → VERIFIED
*** Bug 76663 has been marked as a duplicate of this bug. ***
*** Bug 76366 has been marked as a duplicate of this bug. ***
*** Bug 84442 has been marked as a duplicate of this bug. ***
*** Bug 63383 has been marked as a duplicate of this bug. ***
No longer blocks: 75599
Blocks: 75599
Product: Core → Mozilla Application Suite
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: