Posted By: DCMonkey | Feb 28th, 2008 @ 12:11 AM
page 1 of 1
Comments: 2 | Views: 1521
DCMonkey
DCMonkey
Monkey see, monkey do, monkey will destroy you!
Todd Bishop has an article about the Vista Capable class action suit with a link to the full text of emails related to the case, released by the judge:

http://blog.seattlepi.nwsource.com/microsoft/library/vistaexhibitsone.pdf

Some of the highlights so far are the Sinofsky email quoted in the article, Dell's Vista RTM post mortem, and the chart of Vista crash causes for 2007 on page 47 (NVidia is #1 at around 480000)

Interesting reading for those that followed the whole Vista release saga.
YearOfTheLinuxDesktop
YearOfTheLinuxDesktop
Seven of Niner! Resistance is Futile!
DCMonkey wrote:
Todd Bishop has an article about the Vista Capable class action suit with a link to the full text of emails related to the case, released by the judge:

http://blog.seattlepi.nwsource.com/microsoft/library/vistaexhibitsone.pdf

Some of the highlights so far are the Sinofsky email quoted in the article, Dell's Vista RTM post mortem, and the chart of Vista crash causes for 2007 on page 47 (NVidia is #1 at around 480000)

Interesting reading for those that followed the whole Vista release saga.


why such an high percentual of crashes listed under "Microsoft Coporation"? does that number included crashes in windows code caused by rootkits? I think so, it happened pretty rarely to me to see windows crashing because of MS drivers and most of those crashes were triggered by something else (rootkits, driver that wrote in the wrong memory places, bad memory, et.)
Two reasons for the unexpectedly high Microsoft Corporation count: if a failure isn't known or obvious to the auto-triage system, it might by default go into the Microsoft bucket.  The other reason is that drivers might corrupt data structures or cause similar problems that will only result in a crash down the line, in Microsoft code.  An example of this is if you pass the wrong kind of memory to any of the kernel wait functions.  You'll only find out about this down the line when the wait gets satisfied, and only in some particular circumstances...  in this case it would appear to be a Microsoft component faulting to the auto-triager. 
page 1 of 1
Comments: 2 | Views: 1521
Microsoft Communities