Bug #1692 WinNT STOP error 0x00000024 after installing MySQL
Submitted: 28 Oct 2003 18:53 Modified: 27 Sep 2008 9:27
Reporter: Mark Berry Email Updates:
Status: Won't fix Impact on me:
None 
Category:MySQL Server: Installing Severity:S2 (Serious)
Version:4.0.16-nt OS:Microsoft Windows (Windows NT4 Server SP6a)
Assigned to: Heikki Tuuri CPU Architecture:Any

[28 Oct 2003 18:53] Mark Berry
Description:
I installed MySQL yesterday.  Today my computer crashed with this error, which I had never seen before:

  The bugcheck was: 0x00000024 (0x00190201, 0xfbb27be0, 0xfbb27a1c, 0x801ecc46)

The crash occurred when I opened my accounting software (Quicken) from a workstation.  The data file for the accounting software is on the same server as MySQL.  In other words, the crash apparently occurred just from accessing a file.

How to repeat:
This is an environment-specific error (Pentium Pro 200, 128MB RAM).  It may not be possible to repeat it.

Suggested fix:
The Microsoft knowledge base contains several articles on error 0x00000024.  This is apparently thrown by ntfs.sys, e.g. when too many file handles are open (see for example article 195857).

Using Task Manager, I see that mysqld-nt.exe has 5241 handles open, compared to 784 by the System and 17-284 for most applications.  I suspect that it is this large number of open handles that has caused this error.  So the suggestion is to reduce the handles to levels similar to other programs.  Thank you.
[28 Oct 2003 21:47] Miguel Solorzano
Assuming that the source of the server's crash is due to number of
handles opened like you had reported I have the below comments:

1- Actually mysqld-nt.exe takes approximately that number of handles for
   you reported when the InnoDB engine table is enabled ( the mysqld
   itself only takes around 60 handles at start).
   If you don't use the above table engine you can start the server with
   --skip-innodb for to get a small number of handles opened.
2- The number of InnoDB handles at the start is defined at:

   \innobase\include\os0thread.h

   #define	OS_THREAD_MAX_N		1000 

  which already was dropped from 10000 due to Win9x crash issues.
3- This is the first time I know that NT 4 has this problem when I only got
   with Win9x and poor hardware resources.
4- Are you verified what were the machine resources available before to
   start the server ?

Anyway I assigned Heikki for complementary comments for.
[29 Oct 2003 23:47] Mark Berry
Thank you very much for your prompt reply.

I have disabled InnoDB and it has in fact reduced the file handles to < 100. I am waiting to hear whether One Or Zero Help Desk needs InnoDB, but so far it seems to work without it.

FYI, another symptom of this problem is that backups of this server failed:  after backing up most of the directories, the last 10 directories or so could not be accessed.  This kind of problem is also mentioned in the Microsoft Knowledge Base as a symptom for too many file handles.

Probably this is rare under NT, but this is a small box (Pentium Pro 200, 128MB) already running IIS, DNS, file server, and Symantec AntiVirus, among other things.  I'm putting a new server on my wish list ;).

Out of curiousity:  is this bug tracking system proprietary or is it publically available?  It is the kind of thing I am thinking of implementing...
[30 Oct 2003 1:59] Heikki Tuuri
Hi!

Those 5000 handles are not file handles but event handles.

I developed InnoDB on NT-3.51 and NT-4.0 computers with 32 MB and 64 MB of RAM. Are you sure your hardware is ok, and have you installed all NT service packs?

Regards,

Heikki
[30 Oct 2003 8:59] Mark Berry
Heikki,

Yeah, the system is patched up to Service Pack 6a.  I recently had problems with the MailEnable mail server (on another machine) that was using this system as a file store--my conclusion was that MailEnable had problems accessing files fast enough over the network.  I moved the data files for the MailEnable onto the same machine as the program to solve it.

In this case, mySQL is on the C: drive and its data is on the D: drive (a separate SCSI hard disk), i.e. no network is involved.  At the moment, this machine lists 50 (!) active processes with Mem Usage 130768K / 247688K.

The STOP error has not recurred, and with the reduced file handles, the backup ran successfully this morning.  If I need InnoDB for production, I do have a Win2000 Server that probably has more capacity and could be expanded.  However the web server is currently on the WinNT machine so I was trying to keep things local.

Thanks again for your help!

Mark Berry
[12 Dec 2003 15:53] Michael Widenius
No action for now as this is not something that occour an all systems and there is no obvious fix for this
[15 Dec 2003 10:10] Mark Berry
Thanks for the follow-through. It turns out we won't be implementing the app that uses MySQL at this time, so I have no further information to provide.  Feel free to close this issue if you like.
[22 Sep 2004 18:29] John Penaloza
Hi,

I just had this happen to me with MySQL v4.0.21 on a fully-patched Windows 2003 Server (Athlon XP 2800+, 1GB RAM).

I had set MySQL to run as a service, btw.

Is this the reason: http://support.microsoft.com/?kbid=195857 ?

Any ideas as to fixes and/or can someone help code a patch to help handle the document threads on shutdown?

Thanks,

John
[27 Sep 2008 9:27] Konstantin Osipov
We have no plans to fix this, Windows NT is not one of supported platforms nowadays.