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> 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] > *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> 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] >> *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> 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] >>> 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> >>> To: NT System Admin Issues <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 >>> Phone: 610-807-6459 >>> Fax: 610-807-6003 >>> >>> -----Original Message----- >>> From: 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> >>> >>> Date: Tue, 5 May 2009 02:35:20 >>> To: NT System Admin Issues<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 >>> >>> c - 312.731.3132 >>> >>> >>> -----Original Message----- >>> From: Richard Stovall [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] >>> 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 [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 >>> Date: Mon, 4 May 2009 10:27:27 -0500 >>> To: 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" <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 >>> > Date: Mon, 4 May 2009 08:57:39 -0500 >>> > To: 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 >>> > >>> > P: 217-337-9761 >>> > C: 217-417-1182 >>> > F: 217-337-9761 >>> > 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> wrote on >>> 05/04/2009 >>> >>> > 08:50:58 AM: >>> > >>> > > Do you have Vipre on these VMs? >>> > > >>> > > From: 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 >>> > > >>> > > P: 217-337-9761 >>> > > C: 217-417-1182 >>> > > F: 217-337-9761 >>> > > 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 ? 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/> ~
