Date: Sun, 11 Apr 1999 22:50:25 +0200 Reply-To: chefren Sender: Windows NT BugTraq Mailing List From: chefren Subject: Death by MessageBox In-Reply-To: <3710D929.D6E46401@dds.nl> .. > -------- Original Message -------- > "NT hangs when several threads are calling MessageBox" > > Date: Fri, 9 Apr 1999 13:23:45 -0400 > From: "Sumner, Jeff" > Organization: OARnet > Newsgroups: microsoft.public.win32.programmer.kernel > > Hello, > > We have a server app that has several clients attached to it. When > certain conditions happen on a client, the server app spawns a new > thread that simply calls MessageBox. The thread is created so the main > server thread can still be processing when the message box is displayed. > We have found that when 16 of these threads are created, NT pretty much > hangs until a few of the message boxes are closed. > > I have written a test program to recreate this, and have noticed the > exact same behavior. The test program is a console app that takes an > integer parameter for the number of message boxes to pop up. I ran this > test app while I have the NT performance monitor up. Any number up to > 15 works fine, but as soon as I specify 16 or higher, the task manager > stops dead cold until a couple of the message boxes (and subsequent > threads) are closed. The code for the test program is less than 3K, so > I've included it here. > > <> > I have figured something out since I posted the message. The > MB_SERVICE_NOTIFICATION flag given to MessageBox is causing the problem. > This flag allows an NT service to display a message box, regardless of > who is logged in. The box will still display even if nobody is logged > in. However, NT does not like the 16th box at all. > > If I take this flag out, then each message box is created with its own > window, and each one appears in the task bar, but only if the "Allow > Service to Interact with Desktop" option is enabled for the service > under Control Panel | Services. In this case, NT performs fine when > more than 15 message boxes are specified, but no message boxes will be > displayed if nobody is logged in. > > So, to make the long story short, I am thinking that there is a bug in > NT that causes windows messages to not be processed correctly when > MB_SERVICE_NOTIFICATION is used and the 16th window is popped up. > > Another thing we have tried is scrapping the multithreading and > MessageBox altogether and just making a system call to execute "net send > ", which causes the message to pop up in a window > on the specified machine (as long as the NT Messenger service is > running). The drawback to this is that it appears that the messenger > service only accepts 6 messages at a time. All others get dropped on > the floor until one or more of the first 6 are closed. > > Does anybody have any insights? They would be greatly appreciated. > > Thanks for your time. > > Jeff Sumner > BASSpoiNT Development > BASS, Inc. > sumner@bassinc.com We "tested" it and it "works"... +++chefren -------------------------------------------------------------------------------- Date: Mon, 12 Apr 1999 13:08:55 +0200 Reply-To: chefren Sender: Windows NT BugTraq Mailing List From: chefren Subject: Re: Death by MessageBox Comments: cc: oded horovitz In-Reply-To: <000a01be84b8$40691530$26d873c0@oded.mucom.co.il> On 12 Apr 99, at 10:44, oded horovitz wrote: > Hi, I think i know the solution to your problem :) > > cuze you didn't gave the source for your problem i can > only guess your problem. > > check this key : > HKLM\SYSTEM\CurrentControlSet\Control\Session > Manager\SubSystems\Windows > the default data for this key : > %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows > SharedSection=1024,3072,1024 Windows=On > SubSystemType=Windows ServerDll=basesrv,1 > ServerDll=winsrv:UserServerDllInitialization,3 > ServerDll=winsrv:ConServerDllInitialization,2 > ProfileControl=Off MaxRequestThreads=16 > > so i guess that if u change this value it may solve your > problem. if it do works, notify me please and you can > post it to bugtraq. hope it helps > Oded h. We checked this obscure and largely invisible[0] part of the registry... Indeed, if you set MaxRequestThreads=5 the system halts at 5 messageboxes. It's an ajustable bug... We didn't distribute the source or the .exe intentionally... +++chefren [0] I have a dual 1280x1024 desktop and just found a minor bug in regedit.exe. Even with such a wide desktop I cannot oversee the data of the above key, only about 216 (strange number, I counted just once...) characters appear while I have enough space on my desktop. Double clicking on the separation mark in the header of the registry editor automatically adjusts the column size as expected but not to the right size but this strange 216 size. Manually widening doesn't show any more. -------------------------------------------------------------------------------- Date: Wed, 23 Jun 1999 14:16:30 -0700 From: aleph1@UNDERGROUND.ORG To: BUGTRAQ@netspace.org Subject: Microsoft Security Bulletin (MS99-021) The following is a Security Bulletin from the Microsoft Product Security Notification Service. Please do not reply to this message, as it was sent from an unattended mailbox. ******************************** Microsoft Security Bulletin (MS99-021) -------------------------------------- Patch Available for "CSRSS Worker Thread Exhaustion" Vulnerability Originally Posted: June 23, 1999 Summary ======= Microsoft has released a patch that eliminates a vulnerability in the Microsoft(r) Windows NT(r) CSRSS process that could be used to create a denial of service condition against a machine that allows interactive logons. Frequently asked questions regarding this vulnerability, its background, and the patch can be found at http://www.microsoft.com/security/bulletins/ms99-021faq.asp Issue ===== If all worker threads in CSRSS.EXE are occupied awaiting user input, no other requests can be serviced, effectively causing the server to hang. When user input is provided, processing returns to normal. The patch eliminates the vulnerability by ensuring that the last CSRSS worker thread services only requests that do not require user input. Affected Software Versions ========================== - Microsoft Windows NT 4.0 Workstation - Microsoft Windows NT 4.0 Server - Microsoft Windows NT 4.0 Server, Enterprise Edition Patch Availability ================== The patch is available at ftp://ftp.microsoft.com/bussys/winnt/ winnt-public/fixes/usa/nt40/Hotfixes-PostSP5/CSRSS-fix/ NOTE: A line break has been inserted into the above URL for readability. More Information ================ Please see the following references for more information related to this issue. - Microsoft Security Bulletin MS99-021: Frequently Asked Questions, http://support.microsoft.com/support/bulletins/ms99-021faq.asp. - Microsoft Knowledge Base (KB) article Q2133323, "Exceeding MaxRequestThreads may Cause Windows NT to Hang", http://support.microsoft.com/support/kb/articles/q231/3/23.asp. (Note: It may take 24 hours from the original posting of this bulletin for the KB article to be visible.) - Microsoft Security Advisor web site, http://www.microsoft.com/security/default.asp. Obtaining Support on this Issue =============================== This is a fully supported patch. Information on contacting Microsoft Technical Support is available at http://support.microsoft.com/support/contact/default.asp. Acknowledgments =============== Microsoft acknowledges Jeff Sumner for discovering this vulnerability and reporting it. Revisions ========= - June 23, 1999: Bulletin Created. --------------------------------------------------------------------- THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. (c) 1999 Microsoft Corporation. All rights reserved. Terms of Use. ******************************************************************* You have received this e-mail bulletin as a result of your registration to the Microsoft Product Security Notification Service. You may unsubscribe from this e-mail notification service at any time by sending an e-mail to MICROSOFT_SECURITY-SIGNOFF-REQUEST@ANNOUNCE.MICROSOFT.COM The subject line and message body are not used in processing the request, and can be anything you like. For more information on the Microsoft Security Notification Service please visit http://www.microsoft.com/security/bulletin.htm. For security-related information about Microsoft products, please visit the Microsoft Security Advisor web site at http://www.microsoft.com/security.