I believe one of his "Inside ..." books addresses this too... There are several
cases where memory allocations can be requested as page backed regardless of
physical memory page status.
-sc
-----Original Message-----
From: Micheal Espinola Jr <michealespin...@gmail.com>
Sent: Wednesday, May 06, 2009 5:58 PM
To: NT System Admin Issues <ntsysadmin@lyris.sunbelt-software.com>
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/> ~
