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/> ~
