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