|
|
User Controls
|
New User
|
Login
|
Edit/View My Profile
|
|
|
|
ActiveMac
|
Articles
|
Forums
|
Links
|
News
|
News Search
|
Reviews
|
|
|
|
News Centers
|
Windows/Microsoft
|
DVD
|
ActiveHardware
|
Xbox
|
MaINTosh
|
News Search
|
|
|
|
ANet Chats
|
The Lobby
|
Special Events Room
|
Developer's Lounge
|
XBox Chat
|
|
|
|
FAQ's
|
Windows 98/98 SE
|
Windows 2000
|
Windows Me
|
Windows "Whistler" XP
|
Windows CE
|
Internet Explorer 6
|
Internet Explorer 5
|
Xbox
|
DirectX
|
DVD's
|
|
|
|
TopTechTips
|
Registry Tips
|
Windows 95/98
|
Windows 2000
|
Internet Explorer 4
|
Internet Explorer 5
|
Windows NT Tips
|
Program Tips
|
Easter Eggs
|
Hardware
|
DVD
|
|
|
|
Latest Reviews
|
Applications
|
Microsoft Windows XP Professional
|
Norton SystemWorks 2002
|
|
Hardware
|
Intel Personal Audio Player
3000
|
Microsoft Wireless IntelliMouse
Explorer
|
|
|
|
Site News/Info
|
About This Site
|
Affiliates
|
ANet Forums
|
Contact Us
|
Default Home Page
|
Link To Us
|
Links
|
Member Pages
|
Site Search
|
Awards
|
|
|
|
Credits
©1997/2004, Active Network. All
Rights Reserved.
Layout & Design by
Designer Dream. Content
written by the Active Network team. Please click
here for full terms of
use and restrictions or read our
Privacy Statement.
|
|
|
|
|
|
|
|
Time:
12:12 EST/17:12 GMT | News Source:
ZDNet Australia |
Posted By: Byron Hinson |
Microsoft has laid the blame for half of all Windows crashes on third-party code. Scott Charney, chief security strategist at Microsoft, told developers at the TechEd 2003 conference in Brisbane, that information collected by Dr Watson, the company's reporting tool, revealed that "half of all crashes in Windows are caused not by Microsoft code, but third-party code".
|
|
#1 By
13998 (217.122.34.74)
at
8/13/2003 1:19:57 PM
|
However, the OS should protect itself from 3rd party buggy code and should not crash.
|
#2 By
5912 (217.121.189.8)
at
8/13/2003 2:03:14 PM
|
Zanadoo: I think you should cut back on the alcihol yourself or try to post a message just a single instance for the time being. :)
|
#3 By
11131 (160.81.221.42)
at
8/13/2003 2:06:28 PM
|
Zanadoo is just trying to get his post count up :)
Alister
|
#4 By
16797 (65.48.179.35)
at
8/13/2003 2:31:32 PM
|
Did I get this right: in other words, half of all crashes is caused by MS code ??!
|
#5 By
2332 (216.41.45.78)
at
8/13/2003 3:43:55 PM
|
Windows Memory Architecture 101:
There are two kinds of logical memory in Windows NT/2k/XP/2K3. Kernel and user. When a program runs, it runs it one of these kinds of memory. (In fact, memory allocation is enforced by the OS... it's not phyiscally different.)
Sometimes this is refered to as "Kernel mode" and "User mode".
Kernel mode is reserved for low level stuff like hardware device drivers, certain services that require extremely high availablility and performance (like http.sys on Win2k3), and the kernel itself. It also has the GDI (graphics device interface) so that graphics performance on Windows doesn't suck.
User mode is for everything else. Any programs you double click. And games you play. Internet explorer. Windows Explorer. Windows Media Player. Yadda yadda.
Applications in user mode can do anything they want, they will not be able to crash Windows. User mode memory is completely isolated from kernel mode memory. As far as user mode applications are concerned, the physical memory used for kernel mode memory doesn't even exist. Perhaps you've seen an application crash saying something like "the memory could not be 'read'"? That's because the application is attempting to, for whatever reason, access memory that either doesn't belong to it (different process), or is not User mode memory.
The only 3rd party applications that could crash Windows are drivers, and other kernel mode services. There are a fairly small number of these (as they are very, very hard to write and are only created when they're absolutely necessary), and there really isn't any excuse for them to crash Windows.
There is another way Windows could crash from running User mode code, but it would require a bug in code that is running in Kernel mode that is accessed by User mode code. In other words, a bug in Microsoft's code.
|
#6 By
7797 (63.76.44.252)
at
8/13/2003 6:53:22 PM
|
I agree with RMD.
This post was edited by tgnb on Wednesday, August 13, 2003 at 18:58.
|
#7 By
17918 (24.88.162.1)
at
8/13/2003 7:19:04 PM
|
Windows Memory Architecture 201:
RMD unfortunately this was 95% true in NT 4.0 but not the case in Windows 2000 and Windows XP. Beginning with DirectX 7, and more so in 8.0 some of the DirectSound (audio) and DirectDraw (video) portions of the APIs for developers are now part of kernal mode, which in NT 4.0 were all part of user mode. This was done to speed up access to hardware for video and audio.
This means it is now entirely possible for an application (user mode) to cause a blue screen directly which only used to happen during kernal mode exceptions. Traditionally, user mode exceptions simply caused a Dr. Watson, or a user.dmp, not a kernal mode exception which is a memory.dmp, blue screen, or bugcheck.
Windows 2003 can also run DX8 or DX9, but it's not installed by default and not generally supported. Technically the above could also happen in Win2003.
There are also many other ways that user mode applications can now cause blue screens particularly 0x0000001e bugchecks that could not happen in NT4.
|
#8 By
17918 (24.88.162.1)
at
8/13/2003 7:27:58 PM
|
mOOzilla hangs and lockups are very different from crashes. Hangs are simply when a process is awaiting a response from another process, or waiting for processor time. Crashes are exceptions often caused by an application, driver, or process calling an improper address causing a "crash."
Applications that lock up or hang are poorly written. Both Outlook and IE should be included in that category of applications.
|
#9 By
9589 (68.17.52.2)
at
8/14/2003 12:04:57 AM
|
We have seen a 1/3 less amount of crashes with XP from W2k and that was from 1/3 less amount of crashes with W2K from WinNT 4.0. This, coupled with a user method for creating a new password(s) instead of calling the help desk, has meant that our help desk staff has only grown half as fast and is more tiered and third party software oriented then ever before. All this while we have doubled our size at about the same time that each of these OS's made their debut and now we keep statistics for 80k+ workstations. Moreover, 65% of the help deskp calls are for hardware problems not software.
Of the thousands of Intel based servers (I don't have satistics for Unix or IBM mainframe), we are seeing 80-85% of server downed time due to hardware problems (that is all kinds - routers, switches, etc. not just the servers themselves). And although we are just deploying W2K3 and only in the Web Edition so far, we expect that the hardware incident rate will continue to climb into the high 80's or low 90% of all Intel based server down time. The upshot is that our server admins, dba's, etc. have responsibility for an ever increasing number of servers.
Are total IT labor cost as a percentage of the cost of operations has steadily shrunk over the last seven years while the department, in terms of systems, has steadily grown in size.
What we are going to our hardware vendors with is getting them to design their systems so that they can repair them more easily and that their field technicians are better trained so that they get fixed fast and fixed right the first time.
No wonder you see the desktop in the hands of Microsoft and their role in the server room ratcheting up year over year.
|
#10 By
2332 (65.221.182.2)
at
8/14/2003 12:09:29 AM
|
#15 - unfortunately this was 95% true in NT 4.0 but not the case in Windows 2000 and Windows XP...
I'm aware there are more than just the things I listed that run in kernel mode, which is why I stated "services that require extremely high availablility and performance".
But you're incorrect. It is not possible for a game to crash Windows unless DirectX has a bug in it and the game developer happens to cause it to occur.
Just like any of the libraries of kernel32.dll or any of the other kernel mode APIs, you cannot cause a crash by using them if they are written correctly. If there is a bug in them, then yes, a crash can occur.
Just because I can call a function in a DLL does not give me direct access to that function's memory area. Only that function can cause corruption in its memory area, and therefore only the code running directly in kernel mode can cause Windows to crash.
Drivers crash on QNX, do they bring the system down?
I'm not really familiar with the QNX memory model, but if drivers run in the same memory space as the kernel, then yes, they would. Simple as that. If they run in a different memory space, then QNX is doomed to extremely poor performance and would have to lack any kind of HAL. Not something to be happy about.
How can a preemptive OS lock up a desktop? Outlook 2002 locks it up, IE can lock it up. Because it is all tied so closely. Drivers crash on QNX, do they bring the system down?
Actually, Outlook 2002 and various other apps don't lock up the OS. Try this. When you computer seems to be locked up, ping it from another computer. You'll notice the pings are responded to just fine. Why? Because it's not the kernel that's locked up, it's simply the thread that's updating the GUI, or the thread that handles user input, or whatever the case may be.
It all depends on how that application interacts with the various system services. Usually, the system has a timeout for almost everything. If the application doesn't do what it's supposed to do in a given time frame, it finally gives up. But before then, the system can become sluggish or even non-responsive as far as the GUI goes. Again, this is not a crash.
Also, explorer.exe runs in user mode. This is why, when it crashes, the system does not go with it.
|
|
|
|
|