Problem with XP scheduler?
in [Win32 Kernel]
|
From: Boba on 29 Dec 2009 20:02 "tanix" <tanix(a)mongo.net> wrote in message news:hhc19f$r7h$3(a)news.eternal-september.org... > In article <O9u0FFDiKHA.5380(a)TK2MSFTNGP06.phx.gbl>, "Boba" > <Boba(a)somewhere.net> wrote: >... >>>But you said "Windows is not a proper multitasking OS" > > Is it? > >>I did not say that (though I do partially agree with that). >>Boba TC. not to the depth of my knoweledge. (at least _not_yet_, for sure.) there are situations when windows runs stable for awhile emulating multitasking among internal tasks spawned by itself. boba.
From: Liviu on 29 Dec 2009 20:33 "J de Boyne Pollard" <J.deBoynePollard(a)Tesco.NET> wrote... > MS> "the Win32 server process is considered a critical system > MS> component of Windows NT 3.51, such that if the > MS> CSRSS.EXE process faults the entire Windows NT > MS> operating system is shutdown." > > PB> The phrase "is considered" is particularly interesting. It is > PB> as if whoever wrote it knows it is more of a considered > PB> opinion than a fact. > > It is, nonetheless, a fact, not an opinion. From Windows NT 5 > onwards, the BreakOnTermination flag is set in the EPROCESS structure > for that process. In earlier versions, the Session Manager halts the > system when it detects that a CSRSS process has died. That is technically correct, with further insight at (last comment in) http://blogs.msdn.com/oldnewthing/archive/2008/10/13/8969404.aspx#9005811 and http://blogs.technet.com/markrussinovich/archive/2005/07/24/running-windows-with-no-services.aspx though David Solomon notes in the former that... || [prior to XP] theoretically if you killed or suspended Smss, || and then killed Csrss, the system would not crash (but as noted, || the display went blank)". ....which is in fact consistent with the distinction being discussed before, between a stalled interactive session vs. a dead system overall.
From: Liviu on 29 Dec 2009 20:33 "tanix" <tanix(a)mongo.net> wrote... > > And I tell you, I am seeing a KERNEL screwing up to the point > beyond belief, which is represented by loosing control of the > highest priority device, a mouse, that is ran by the kernel, > and nothing less. Let me get this straight... You have a rather singular issue which others seem to neither have, nor be able to duplicate, yet people tried to help and volunteered good advice (repeatedly). You chose to ignore that advice, or shrugged it off as you don't "think" it is a driver bug, instead you are "telling" us that you are "seeing" a kernel screwup. Sure, that'll convince everybody in a technical newsgroup, and build your credibility sky-high up, too ;-) If you are serious about finding/fixing the actual issue, then first thing unplug your usb mouse, reboot into safe mode (with networking) and see if the issue persists. Unless and until you do that, maybe think twice about reciting the "it's windows' fault" mantra ad nauseam, lest risk being (mis)taken for a preprogrammed troll. Liviu
From: Alexander Grigoriev on 29 Dec 2009 21:58 For further amusement (and more insight into this person's character), dig out a great "MFC Goldmine" thread(s). "Liviu" <lab2k1(a)gmail.c0m> wrote in message news:%23F5DFBPiKHA.1536(a)TK2MSFTNGP06.phx.gbl... > "tanix" <tanix(a)mongo.net> wrote... >> >> And I tell you, I am seeing a KERNEL screwing up to the point >> beyond belief, which is represented by loosing control of the >> highest priority device, a mouse, that is ran by the kernel, >> and nothing less. > > Let me get this straight... You have a rather singular issue which > others seem to neither have, nor be able to duplicate, yet people > tried to help and volunteered good advice (repeatedly). You chose > to ignore that advice, or shrugged it off as you don't "think" it is a > driver bug, instead you are "telling" us that you are "seeing" a kernel > screwup. Sure, that'll convince everybody in a technical newsgroup, > and build your credibility sky-high up, too ;-) > > If you are serious about finding/fixing the actual issue, then first > thing unplug your usb mouse, reboot into safe mode (with networking) > and see if the issue persists. Unless and until you do that, maybe > think twice about reciting the "it's windows' fault" mantra ad nauseam, > lest risk being (mis)taken for a preprogrammed troll. > > Liviu > >
From: tanix on 29 Dec 2009 23:33
In article <emgj$XLiKHA.1824(a)TK2MSFTNGP04.phx.gbl>, "Don Burn" <burn(a)stopspam.windrvr.com> wrote: > >I would love to hear your definition of a "truly multitaking OS". About all >that anyone can agree on is that a multitasking OS supports multiple tasks. >This has been a debate for a very long time, depending on the definition >locking all the other processes including display is not only ok, it is >expected. Btw, do you realize what you did, mr. smart by top poting and leaving the original material AFTER you sig? Well, your paragraph above is ALL that is left for someone, who is going to find this article via web. So, if you do THESE kinds of screwups, what can you possibly argue as far as "truly multitasking OS" goes? Well, for one thing, truly multitasking OS would NEVER exhibit such a behavior. Just imagine the IBM mainframes on Wall St. behaving like this? Or some major banks, or you name it? Do you realize what would happend in the world? On nuclear plants, public transportation system, water supply facilities and ALL sorts of things in the real world? Anyway, following is what was stripped out as a result of your "holier than thou" arrogant style of presentation. For one thing, top posting is problably the most disgusting signature, despised more then most other things as it demonstrates utter I-don't-care-lessness and "holier thatn thou" arrogance, exhibited by some smart fart, that things what HE has to say is nothing less then the word of God. So, here is the rest of the article that would be gone if I did not restore it manyally by copy/paste: (Do you see the difference between reality and fiction?) ===== Quote begin ===== -- Don Burn (MVP, Windows DKD) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr Remove StopSpam to reply "tanix" <tanix(a)mongo.net> wrote in message news:hhdfs1$1it$8(a)news.eternal-september.org... > In article <hhcoup$8am$1(a)atlantis.news.neostrada.pl>, > =?ISO-8859-1?Q?Grzegorz_Wr=F3bel?= > </dev/null(a)localhost.localdomain> wrote: >>Tim Roberts wrote: >>> Grzegorz Wr�bel </dev/null(a)localhost.localdomain> wrote: >>> >>>> Tim Roberts wrote: >>>>> Get real. A software problem cannot cause your machine to lock up so >>>>> hard >>>>> that even mouse and keyboard stop. >>>> Get rational. User mode app can lock up mouse and keyboard just by >>>> starving system processes that manage mouse and keyboard input. On the >>>> single CPU/core machines it was very common to happen. On the multi >>>> core >>>> machines much less likely to happen "naturally", but still possible. >>> >>> No. A user mode app can certainly prevent other user mode apps from >>> processing mouse and keyboard input, yes, but the mouse pointer keeps >>> moving, and pressing the caps lock key still toggles the caps lock >>> indicator. Stopping those requires the "assistance" of kernel code. >> >>No. The point is you can lock mouse and keyboard to the point that the >>mouse cursor stops moving and no other application (including Windows >>shell) can receive/process mouse and keyboard input. > > ONLY in not truly multitasking OS. > >>This is known issue, if you have never experienced it as a programmer, >>you still can read about it in MSDN: >>http://msdn.microsoft.com/en-us/library/ms685100(VS.85).aspx > > You can read all you want. > > Enough of this. > >>You can of course argue this is still "kernel code" that freezes the >>box, but such argumentation doesn't have much sense since this code is >>executed directly by user mode API calls. >> >> >>This is the sample test code I once wrote to effectively freeze the >>single CPU/core Windows box for 30 seconds (on post XP system you'll >>need to run it elevated otherwise SetPriorityClass() will fail): >> >>//lockme.cpp >> >># include <windows.h> >># include <math.h> >> >>int main() >>{ >> int i,j,k; >> double a,b,c; >> ULARGE_INTEGER start,current; >> SYSTEMTIME st; >> FILETIME ft; >> >> SetPriorityClass(GetCurrentProcess(),REALTIME_PRIORITY_CLASS); >> >> SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_TIME_CRITICAL); >> >> GetSystemTime(&st); >> SystemTimeToFileTime(&st,&ft); >> memcpy(&start,&ft,sizeof(ft)); >> >> for(;;){ //lets do some heavy computation; >> c = 0.9; >> a = sin(c); >> b = cos(c); >> c = log(pow(a,b)+c); >> k = int(c)+5; >> j = 4*k*k*k + 2*k*k + k + 1; >> >> GetSystemTime(&st); >> SystemTimeToFileTime(&st,&ft); >> memcpy(¤t,&ft,sizeof(ft)); >> if(current.QuadPart-start.QuadPart>300000000) // release >> the >> lock >>after 30 seconds >> break; >> } >> >> return 0; >>} >> >> >>The above code simply sets its base priority to 31 and then occupy CPU. >> >>Haven't tried it on multicore box, but presumably if you run it from >>elevated console n times (when n is number of the CPU cores) you should >>freeze the box too. Unless OS tries to reserve one core for itself >>(unlikely). >> >> > > -- > Programmer's Goldmine collections: > > http://preciseinfo.org > > Tens of thousands of code examples and expert discussions on > C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, > organized by major topics of language, tools, methods, techniques. > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4726 (20091229) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4726 (20091229) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ===== Quote end ===== -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, organized by major topics of language, tools, methods, techniques. |