Lots and lots of device drivers check major version Ids. My understanding (and I don't write device drivers so I'm not sure of this) was that until Vista/Win2008, a driver had no mechanism for checking OS capabilities except to look at the version number of the OS.
As of Vista/Win2008 drivers can check for individual feature/functionalities that they require, but that requires a major rewrite. Most driver vendors just did the minimum necessary to get their drivers functioning on Vista/Win2008. Except for a few bug fixes and a few new features, nothing has theoretically changed in the device driver interface for Win7; so....don't break the existing drivers. That was one of the major reasons people claimed to not move up to Vista (which is also ironic, since Win7 uses the Vista driver model - not the XP driver model). ________________________________ From: Micheal Espinola Jr [michealespin...@gmail.com] Sent: Wednesday, May 06, 2009 9:01 PM To: NT System Admin Issues Subject: Re: Memory Dumps on large RAM OS I've heard this, but is that a *truly* legit reason to disregard proper development/release numbering? What exactly is it going to break that cannot be properly compensated for with patching/updates? -- ME2 On Wed, May 6, 2009 at 8:56 PM, Ken Schaefer <k...@adopenstatic.com<mailto:k...@adopenstatic.com>> wrote: What dancing around? I thought it was for backwards compat? Windows Server 2008 R2 isn't getting a new version number AFAIK. Cheers Ken ________________________________ From: Micheal Espinola Jr [michealespin...@gmail.com<mailto:michealespin...@gmail.com>] Sent: Thursday, 7 May 2009 10:52 AM To: NT System Admin Issues Subject: Re: Memory Dumps on large RAM OS I love how Microsoft has been dancing around why "7" doesn't have a new major release number (i.e 7.0), and is still within the 6.x cycle. -- ME2 On Wed, May 6, 2009 at 8:34 PM, Michael B. Smith <mich...@owa.smithcons.com<mailto:mich...@owa.smithcons.com>> wrote: what you commonly see in the non-public presentations is "why" something is the way it is and some discussions about tradeoffs. in general, microsoft thinks that customers don't want to hear about implementation tradeoffs. i would say that for your average end-user, that's true. for your above-average tech., probably not so much. however, even in the non-public presentations, the discussions often get bogged down in "why isn't this optional" and people expressing opinions that a decision was made improperly. when you have the attention of the people who wrote the code or can change the code, it's hard not to have an agenda. microsoft prefers to keep those kinds of discussions under control. i would too. :-) too many knobs to turn and buttons to push makes support impossible, implementation ridiculously complicated, and code even more bloated than it already is to meet the feature requests of customers. let's take an example: Vista. Vista is what people asked for. Pretty and glitzy and new and secure and blah blah blah. But to run well, it took much faster hardware, lots more memory, better graphics cards, etc. etc. People didn't want to pay for that. Microsoft paid the price for giving the public what they asked for. (Yes, yes, yes, they made some poor decisions too, but that doesn't change my core point.) Win7 is Vista Reloaded. I don't care what you want to call it. It's optimized and to reduce the memory footprint, lots of services were made optional (decoupled), the graphics aren't as glitzy (unless you ask for them) and the kernel handles multi-cores better. Lots of the knobs and buttons that Vista exposed are now hidden; still there, but now under the covers. anyway, i'm in a philosophical mood and i digress... ________________________________ From: Micheal Espinola Jr [michealespin...@gmail.com<mailto:michealespin...@gmail.com>] Sent: Wednesday, May 06, 2009 5:58 PM To: NT System Admin Issues Subject: Re: Memory Dumps on large RAM OS That would be most excellent of them to make available. Do you need Secret Squirrel level clearance? -- ME2 On Wed, May 6, 2009 at 4:57 PM, Michael B. Smith <mich...@owa.smithcons.com<mailto:mich...@owa.smithcons.com>> wrote: Yes, and they take a damn long time to transfer too. Best practice for pagefile size on 64-bit Exchange Servers is RAM + 15 MB. And page file space is only loosely correlated to "paging out". I've got a great presentation on this topic that was made in a closed forum by Mark Russinovich (of sysinternals fame), but I don't think it was ever made public. Regardless, RAM + 15 MB is a good place to start (on x64), then adjust as necessary for your environment. ________________________________________ From: Don Kuhlman [drkuhl...@yahoo.com<mailto:drkuhl...@yahoo.com>] Sent: Wednesday, May 06, 2009 1:33 PM To: NT System Admin Issues Subject: Memory Dumps on large RAM OS Ps - just a thought or another question. With the RAM capacity of the newer Windows OS - 32 gig of RAM, are people generally just setting up the crash dump recovery on Windows to use the small memory dump, or some other setting besides a full dump? In theory, if you have a server with 32 gig of RAM, and if you wanted a full dump, you'd need a 32 gig page file which seems like a huge waste of space, because (in theory), the server with this much RAM would never be paging out especially to a page file that big, right? So how would you capture a dump? Don K ----- Original Message ---- From: Christopher Bodnar <christopher_bod...@glic.com<mailto:christopher_bod...@glic.com>> To: NT System Admin Issues <ntsysadmin@lyris.sunbelt-software.com<mailto:ntsysadmin@lyris.sunbelt-software.com>> Sent: Tuesday, May 5, 2009 7:34:27 AM Subject: RE: Frequent crashes on a virtual machine You might want to check out this: http://technet.microsoft.com/en-us/sysinternals/bb963887.aspx Mark Russinovich's webcast on Crash Dump analysis might be of help to you. Chris Bodnar, MCSE Sr. Systems Engineer Distributed Systems Service Delivery - Intel Services Guardian Life Insurance Company of America Email: christopher_bod...@glic.com<mailto:christopher_bod...@glic.com> Phone: 610-807-6459 Fax: 610-807-6003 -----Original Message----- From: drkuhl...@yahoo.com<mailto:drkuhl...@yahoo.com> [mailto:drkuhl...@yahoo.com<mailto:drkuhl...@yahoo.com>] Sent: Tuesday, May 05, 2009 8:26 AM To: NT System Admin Issues Subject: Re: Frequent crashes on a virtual machine Anyone ever see a situaition where the server doesn't write a mini or any other dump when it crashes? Better yet, does someone have a link to some good dump analysis site(s) ? Thanks Don k Sent from my BlackBerryR smartphone with SprintSpeed -----Original Message----- From: Brian Desmond <br...@briandesmond.com<mailto:br...@briandesmond.com>> Date: Tue, 5 May 2009 02:35:20 To: NT System Admin Issues<ntsysadmin@lyris.sunbelt-software.com<mailto:ntsysadmin@lyris.sunbelt-software.com>> Subject: RE: Frequent crashes on a virtual machine A kernel dump is good enough. You'll get a mini for free. You should do this on one of the crashing guests. Sorry if that wasn't clear. Thanks, Brian Desmond br...@briandesmond.com<mailto:br...@briandesmond.com> c - 312.731.3132 -----Original Message----- From: Richard Stovall [mailto:richard.stov...@researchdata.com<mailto:richard.stov...@researchdata.com>] Sent: Monday, May 04, 2009 9:00 PM To: NT System Admin Issues Subject: RE: Frequent crashes on a virtual machine I've got tons of minidumps from this issue. All I know how to do is run them through WinDbg, and I always come up with PFN_LIST_CORRUPT. Per the suggestions here, I will turn on verifier.exe on one of the affected servers. Should I have it create a minidump, kernel dump, or full memory dump? What can I do differently with the dump file to pinpoint what's going on? I'm really at my wit's end with this. It's been going on ever since I began installing Sunbelt's Vipre on our servers. Thanks very much for the help. RS -----Original Message----- From: Ken Schaefer [mailto:k...@adopenstatic.com<mailto:k...@adopenstatic.com>] Sent: Monday, May 04, 2009 9:33 PM To: NT System Admin Issues Subject: RE: Frequent crashes on a virtual machine 0x4E is FPN_LIST_CORRUPT. This is unlikely to be caused by the host machine, especially if the VM is bluescreening with the same STOP code over and over. Usually 0x4E is a faulty kernel module of some kind (driver, file system filter or similar). Can we get access to a minidump file(s)? Brian's suggestion of turning on verifier.exe is also a good idea. It won't stop the BSODs, but it will catch the culprit in the act (e.g. when something writes to memory it shouldn't be) and make the dump files much better. Cheers Ken ________________________________________ From: mse...@ont.com<mailto:mse...@ont.com> [mse...@ont.com<mailto:mse...@ont.com>] Sent: Tuesday, 5 May 2009 1:50 AM To: NT System Admin Issues Subject: RE: Frequent crashes on a virtual machine Is there anything in under events for that VM? Also, check under /var/log for that ESX host to see if you have any errors. Original Message: ----------------- From: richardmccl...@aspca.org<mailto:richardmccl...@aspca.org> Date: Mon, 4 May 2009 10:27:27 -0500 To: ntsysadmin@lyris.sunbelt-software.com<mailto:ntsysadmin@lyris.sunbelt-software.com> Subject: RE: Frequent crashes on a virtual machine Thanks, but it doesn't apply here. This was a VM "built from scratch" from the VM console. It was never a physical machine. -- Richard "mse...@ont.com<mailto:mse...@ont.com>" <mse...@ont.com<mailto:mse...@ont.com>> wrote on 05/04/2009 10:14:14 AM: > Did you do cleanup after you P2V'd your server? > > Open a command prompt on the Windows VM (Start --> Run --> cmd). > set devmgr_show_nonpresent_devices=1 > devmgmt.msc > In the device management console (View --> Show Hidden Devices). > Uninstall the devices that are no longer required. Such as old network > devices. > > Mike > > Original Message: > ----------------- > From: richardmccl...@aspca.org<mailto:richardmccl...@aspca.org> > Date: Mon, 4 May 2009 08:57:39 -0500 > To: > ntsysadmin@lyris.sunbelt-software.com<mailto:ntsysadmin@lyris.sunbelt-software.com> > Subject: RE: Frequent crashes on a virtual machine > > > Yes. > > The crashes do not necessarily coincide with VIPRE scans, etc. > -- > Richard D. McClary > Systems Administrator, Information Technology Group > > ASPCA(r) > 1717 S. Philo Rd, Ste 36 > Urbana, IL 61802 > > richardmccl...@aspca.org<mailto:richardmccl...@aspca.org> > > P: 217-337-9761 > C: 217-417-1182 > F: 217-337-9761 > www.aspca.org<http://www.aspca.org> > > The information contained in this e-mail, and any attachments hereto, is > from The American Society for the Prevention of Cruelty to Animals(r) (ASPCA > (r)) and is intended only for use by the addressee(s) named herein and may > contain legally privileged and/or confidential information. If you are not > the intended recipient of this e-mail, you are hereby notified that any > dissemination, distribution, copying or use of the contents of this > e-mail, and any attachments hereto, is strictly prohibited. If you have > received this e-mail in error, please immediately notify me by reply email > and permanently delete the original and any copy of this e-mail and any > printout thereof. > > > "Richard Stovall" > <richard.stov...@researchdata.com<mailto:richard.stov...@researchdata.com>> > wrote on 05/04/2009 > 08:50:58 AM: > > > Do you have Vipre on these VMs? > > > > From: richardmccl...@aspca.org<mailto:richardmccl...@aspca.org> > > [mailto:richardmccl...@aspca.org<mailto:richardmccl...@aspca.org>] > > Sent: Monday, May 04, 2009 9:43 AM > > To: NT System Admin Issues > > Subject: Frequent crashes on a virtual machine > > > > > > Greetings! > > > > Most of our user files are being moved to a VMWare VM. What is > > disturbing is, when I log in, I am frequently greeting with a notice > > that the machine re-booted from a crash... > > > > My users have never noticed anyting amiss as it reboots pretty > > quickly (so far). However, once it did this while it was being > > backed up, so a bunch of user files were skipped that day. > > > > I get this set of messages: > > > > Category (102) Event ID: 1003 > > > > Error code 0000004e, parameter1 0000009a, parameter2 00009028, > > parameter3 00000006, parameter4 00000002. > > > > Again, this is a VM. Google searches pretty much all point to > > solutions on a physical machine. > > > > Thanks! > > -- > > Richard D. McClary > > Systems Administrator, Information Technology Group > > > > ASPCA(r) > > 1717 S. Philo Rd, Ste 36 > > Urbana, IL 61802 > > > > richardmccl...@aspca.org<mailto:richardmccl...@aspca.org> > > > > P: 217-337-9761 > > C: 217-417-1182 > > F: 217-337-9761 > > www.aspca.org<http://www.aspca.org> > > > > The information contained in this e-mail, and any attachments > > hereto, is from The American Society for the Prevention of Cruelty to > Animals(r) > > (ASPCA(r)) and is intended only for use by the addressee(s) named > > herein and may contain legally privileged and/or confidential > > information. If you are not the intended recipient of this e-mail, > > you are hereby notified that any dissemination, distribution, > > copying or use of the contents of this e-mail, and any attachments > > hereto, is strictly prohibited. If you have received this e-mail in > > error, please immediately notify me by reply email and permanently > > delete the original and any copy of this e-mail and any printout > thereof. > > > > > > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > -------------------------------------------------------------------- > mail2web.com<http://mail2web.com> ? What can On Demand Business Solutions do > for you? > http://link.mail2web.com/Business/SharePoint > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ -------------------------------------------------------------------- mail2web LIVE - Free email based on Microsoft(r) Exchange technology - http://link.mail2web.com/LIVE ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ----------------------------------------- This message, and any attachments to it, may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are notified that any use, dissemination, distribution, copying, or communication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by return e-mail and delete the message and any attachments. Thank you. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
