The answer to an old question ...

The question: What on Earth would you do with a 64GB memory?

Read on for the answer!

A few nights ago I ran Check Disk with discover and recover options on a
4TB HD. It was a disk that could be dismounted while Win 7 PRO SP1 64
bit continued running. It took quite a while to finish. When I looked at
the Task Manager's Performance Screen during this operation I noted that
the claim was 63.6GB Physical Memory in use.

Things seemed to return to normal when the Check Disk run completed.
However, I noticed later that a MalwareBytes process was now holding
63+GB private memory. I rebooted at this point.

I understand Check Disk grabbing all the memory it could for buffers -
easier to grab then reason about reasonable behavior - but I'm puzzled
by MalwareBytes' behavior. Anyone want to venture an opinion, informed
or otherwise, about that?
--
Jeff Barnett

On 27 Jan 2018, Jeff Barnett wrote in
alt.windows7.general:

I understand Check Disk grabbing all the memory it could for
buffers - easier to grab then reason about reasonable behavior -
but I'm puzzled by MalwareBytes' behavior. Anyone want to venture
an opinion, informed or otherwise, about that?

I would call that a bug. I've already lost confidence in Malwarebytes
Anti-Malware, so this just adds to my gripe list.

The thinking these days is that it's OK for a program to use as much
free memory as it wants... as long as it willingly gives it up when
other programs need it. Malwarebytes is not doing that, and is
therefore a bad neighbor and should be run out of town on a rail.

On 01/27/2018 4:28 PM, Jeff Barnett wrote:
The question: What on Earth would you do with a 64GB memory?

Read on for the answer!

A few nights ago I ran Check Disk with discover and recover options on a
4TB HD. It was a disk that could be dismounted while Win 7 PRO SP1 64
bit continued running. It took quite a while to finish. When I looked at
the Task Manager's Performance Screen during this operation I noted that
the claim was 63.6GB Physical Memory in use.

Things seemed to return to normal when the Check Disk run completed.
However, I noticed later that a MalwareBytes process was now holding
63+GB private memory. I rebooted at this point.

I understand Check Disk grabbing all the memory it could for buffers -
easier to grab then reason about reasonable behavior - but I'm puzzled
by MalwareBytes' behavior. Anyone want to venture an opinion, informed
or otherwise, about that?

Yes,take a look in A.C.O Windows-10 under subject "ping Char Jackson"
and you will see more of the same.

Rene

Jeff Barnett wrote:

The question: What on Earth would you do with a 64GB memory?

Read on for the answer!

A few nights ago I ran Check Disk with discover and recover options on a
4TB HD. It was a disk that could be dismounted while Win 7 PRO SP1 64
bit continued running. It took quite a while to finish. When I looked at
the Task Manager's Performance Screen during this operation I noted that
the claim was 63.6GB Physical Memory in use.

Things seemed to return to normal when the Check Disk run completed.
However, I noticed later that a MalwareBytes process was now holding
63+GB private memory. I rebooted at this point.

I understand Check Disk grabbing all the memory it could for buffers -
easier to grab then reason about reasonable behavior - but I'm puzzled
by MalwareBytes' behavior. Anyone want to venture an opinion, informed
or otherwise, about that?

A process was allocated 64 GB. Not only is that a huge consumption by
one process but you also must have something like 128 GB, or more, on
the motherboard in its memory slots. There's no way one process could
suck up 64 GB of system RAM if that was the maximum memory capacity.
What motherboard are you using that can support 128 GB, or more?

http://www.zdnet.com/article/max-mem...bit-windows-7/

I take it that you must have the Pro, Enterprise, or Ultimate edition of
Windows 7 so that OS will support more than the 16 GB max for the Home
edition. I'm still interested in what make and model motherboard you
have and what memory modules (RAM) you have in your setup.

KenW wrote on 1/27/2018 4:31 PM:
On Sat, 27 Jan 2018 15:28:03 -0700, Jeff Barnett
wrote:

The question: What on Earth would you do with a 64GB memory?

Read on for the answer!

A few nights ago I ran Check Disk with discover and recover options on a
4TB HD. It was a disk that could be dismounted while Win 7 PRO SP1 64
bit continued running. It took quite a while to finish. When I looked at
the Task Manager's Performance Screen during this operation I noted that
the claim was 63.6GB Physical Memory in use.

Things seemed to return to normal when the Check Disk run completed.
However, I noticed later that a MalwareBytes process was now holding
63+GB private memory. I rebooted at this point.

I understand Check Disk grabbing all the memory it could for buffers -
easier to grab then reason about reasonable behavior - but I'm puzzled
by MalwareBytes' behavior. Anyone want to venture an opinion, informed
or otherwise, about that?

A bad update was put out. Back to normal with new update. At least it
wasn't like antivirus wiping out Windows because of an FP.

The bad update was for MalwareBytes or Check Disk?
--
Jeff Barnett

VanguardLH wrote:
Jeff Barnett wrote:

The question: What on Earth would you do with a 64GB memory?

Read on for the answer!

A few nights ago I ran Check Disk with discover and recover options on a
4TB HD. It was a disk that could be dismounted while Win 7 PRO SP1 64
bit continued running. It took quite a while to finish. When I looked at
the Task Manager's Performance Screen during this operation I noted that
the claim was 63.6GB Physical Memory in use.

Things seemed to return to normal when the Check Disk run completed.
However, I noticed later that a MalwareBytes process was now holding
63+GB private memory. I rebooted at this point.

I understand Check Disk grabbing all the memory it could for buffers -
easier to grab then reason about reasonable behavior - but I'm puzzled
by MalwareBytes' behavior. Anyone want to venture an opinion, informed
or otherwise, about that?

A process was allocated 64 GB. Not only is that a huge consumption by
one process but you also must have something like 128 GB, or more, on
the motherboard in its memory slots. There's no way one process could
suck up 64 GB of system RAM if that was the maximum memory capacity.
What motherboard are you using that can support 128 GB, or more?

http://www.zdnet.com/article/max-mem...bit-windows-7/

I take it that you must have the Pro, Enterprise, or Ultimate edition of
Windows 7 so that OS will support more than the 16 GB max for the Home
edition. I'm still interested in what make and model motherboard you
have and what memory modules (RAM) you have in your setup.

You need at least Win7 Pro (the lowest SKU practical for
Win7 and large memory).

I run 64GB on the Test Machine, on a 4930K, and
a single process can take all the memory on the machine
when using a x64 OS. A practical example is the usage
of Microsoft ICE Panorama software, which has used that
much, and really wants more if it could get it.

And a process doesn't have to be intelligent to use
up memory. The x64 CHKDSK was a rather famous example
of "being stupid". But you can craft your own programs
if you like.

Take for example, the following program. It's short,
and will flog the machine for memory, until at
some point a NULL comes back. The program does
real writes to memory, to keep the process "honest"
and I get real memory and not fake memory or
"lazy evaluation" behavior. The control-C handler
I put in here, is effectively useless and I should
really remove that code - I was hoping it would
make control-C more responsive.

*******
#include stdio.h
#include stdlib.h
#include string.h
#include windows.h

/* gcc -o malloc.exe -Wl,--large-address-aware malloc.c */

BOOL WINAPI handler(DWORD dwCtrlType)
{
if (CTRL_C_EVENT == dwCtrlType)
{
exit(0);
}
return FALSE;
}

int main (int argc, char *argv[])
{
SetConsoleCtrlHandler(handler, TRUE);

__int64 time1 = 0, time2 = 0, freq = 0;
QueryPerformanceCounter((LARGE_INTEGER *) &time1);
QueryPerformanceFrequency((LARGE_INTEGER *)&freq);

int i = 0;
void *m;

while ( (m = malloc(1024*1024)) != NULL ) {
memset(m,0,1024*1024);
i++;
QueryPerformanceCounter((LARGE_INTEGER *) &time2);
/* t is the time to malloc a megabyte of RAM, a measure of memory pressure */
printf("%05d megabytes t=%010.6f\n", i, (float)(time2-time1)/freq);
}
}
*******

As for CHKDSK, that one is easy to solve. If you don't
like the behavior of CHKDSK on the x64 OS, find your
x32 OS installer DVD and grab the x32 version of CHKDSK.
It will use up 2GB of RAM or so, rather than the whole
machine. Such a practice would be good for Malwarebytes,
if you were allowed to run a 32 bit version on a 64 bit
machine. While the industry is working to eliminate 32 bit
programs, the "quota" behavior on memory from using
32 bit, does provide a convenient work-around in
cases like this. Not all programs though, give you
granular control over what version gets installed
(like running the 32 bit version on a 64 bit OS).

The current (unnecessary) limit for desktop systems at
the moment, is 128GB. ThreadRipper boards supports "only" 8x16GB,
because the server makers don't want cheap desktop mobos
cutting into their sales margins. A ThreadRipper board
could probably take 1TB of RAM, if decent modules could
be plugged into the DIMM socket type. So a desktop user
could have a "big" machine, but the desktop profile
prevents manufacturers from doing that.

The next best thing, is a single socket Epyc. There's one
that the motherboard is desktop-sized, only uses
eight of a possible sixteen DIMM slots, and you're
"allowed" to use 128GB LR DIMMs in that one. It's
because the board is coming from a server manufacturer
(Supermicro).

It's possible for some programs to have bad behavior
above 64GB... but my machine isn't big enough to test
for that. And memory is too expensive to have fun any more.
To build a "decent" machine now, you'd be putting $3200
of RAM in it :-) An "excessive" amount of RAM costs $24,000.
(That's the amount of RAM, that it takes too long to
initialize every day. Reboots would suck.) The mere 64GB of
my machine, isn't really a problem on reboots. I don't
consider my machine to be all that big. It's when the
machine takes a while to POST, that you get the message,
and the $24000 worth of RAM case... would be slow.
You would be reminded every time "what was I thinking"
on a reboot. Not good. And you can't really put an
advert in the paper "$24000 RAM for sale, $50 or
best offer" :-) Think of the hooligans that would
attract.

Paul

VanguardLH wrote on 1/27/2018 5:10 PM:
Jeff Barnett wrote:

The question: What on Earth would you do with a 64GB memory?

Read on for the answer!

A few nights ago I ran Check Disk with discover and recover options on a
4TB HD. It was a disk that could be dismounted while Win 7 PRO SP1 64
bit continued running. It took quite a while to finish. When I looked at
the Task Manager's Performance Screen during this operation I noted that
the claim was 63.6GB Physical Memory in use.

Things seemed to return to normal when the Check Disk run completed.
However, I noticed later that a MalwareBytes process was now holding
63+GB private memory. I rebooted at this point.

I understand Check Disk grabbing all the memory it could for buffers -
easier to grab then reason about reasonable behavior - but I'm puzzled
by MalwareBytes' behavior. Anyone want to venture an opinion, informed
or otherwise, about that?

A process was allocated 64 GB. Not only is that a huge consumption by
one process but you also must have something like 128 GB, or more, on
the motherboard in its memory slots. There's no way one process could
suck up 64 GB of system RAM if that was the maximum memory capacity.
What motherboard are you using that can support 128 GB, or more?

http://www.zdnet.com/article/max-mem...bit-windows-7/

I take it that you must have the Pro, Enterprise, or Ultimate edition of
Windows 7 so that OS will support more than the 16 GB max for the Home
edition. I'm still interested in what make and model motherboard you
have and what memory modules (RAM) you have in your setup.

I am using an Asus x-79 Deluxe motherboard with G.SKILL Ripjaws Z Series
64GB (8 x 8GB) 240-Pin DDR3 SDRAM DDR3 2400 (PC3 19200) Desktop Memory
Model F3-19200CL10Q2-64GBZHD. As I said above, I'm running Win 7 PRO SP1
64 bit. Your assumption about what a process can suck up is incorrect.
--
Jeff Barnett

Jeff Barnett wrote:

VanguardLH wrote on 1/27/2018 5:10 PM:
Jeff Barnett wrote:

The question: What on Earth would you do with a 64GB memory?

Read on for the answer!

A few nights ago I ran Check Disk with discover and recover options on a
4TB HD. It was a disk that could be dismounted while Win 7 PRO SP1 64
bit continued running. It took quite a while to finish. When I looked at
the Task Manager's Performance Screen during this operation I noted that
the claim was 63.6GB Physical Memory in use.

Things seemed to return to normal when the Check Disk run completed.
However, I noticed later that a MalwareBytes process was now holding
63+GB private memory. I rebooted at this point.

I understand Check Disk grabbing all the memory it could for buffers -
easier to grab then reason about reasonable behavior - but I'm puzzled
by MalwareBytes' behavior. Anyone want to venture an opinion, informed
or otherwise, about that?

A process was allocated 64 GB. Not only is that a huge consumption by
one process but you also must have something like 128 GB, or more, on
the motherboard in its memory slots. There's no way one process could
suck up 64 GB of system RAM if that was the maximum memory capacity.
What motherboard are you using that can support 128 GB, or more?

http://www.zdnet.com/article/max-mem...bit-windows-7/

I take it that you must have the Pro, Enterprise, or Ultimate edition of
Windows 7 so that OS will support more than the 16 GB max for the Home
edition. I'm still interested in what make and model motherboard you
have and what memory modules (RAM) you have in your setup.

I am using an Asus x-79 Deluxe motherboard with G.SKILL Ripjaws Z Series
64GB (8 x 8GB) 240-Pin DDR3 SDRAM DDR3 2400 (PC3 19200) Desktop Memory
Model F3-19200CL10Q2-64GBZHD. As I said above, I'm running Win 7 PRO SP1
64 bit. Your assumption about what a process can suck up is incorrect.

Thanks for the info about your hardware and Win7 edition. You aren't
running multiple concurrently active (on-demand aka realtime) anti-
malware programs, right?

How could a process while running under an OS suck up all the memory so
the OS has no memory? As Paul mentioned, a process can suck up a lot of
memory but there still has to be some for the OS.

Although I've tried several products from Malwarebytes, I gave up on all
of them. They all have slowed my computer more than other similar
security programs. Anything you add for security will slow the computer
but it shouldn't be significant or prolonged. Security software is to
protect the computer, not the primary use of the computer.

Malwarebytes Update Released to Fix High CPU & Memory Usage in
Mbamservice.exe
https://www.bleepingcomputer.com/new...amservice-exe/
(January 27, 2018)

Looks like Malwarebytes ****ed up. Have you tried the new update? I
didn't bother to check if it is actually available or if Malwarebytes is
just making an announcement.

VanguardLH wrote on 1/27/2018 10:40 PM:
Jeff Barnett wrote:

VanguardLH wrote on 1/27/2018 5:10 PM:
Jeff Barnett wrote:

The question: What on Earth would you do with a 64GB memory?

Read on for the answer!

A few nights ago I ran Check Disk with discover and recover
options on a 4TB HD. It was a disk that could be dismounted
while Win 7 PRO SP1 64 bit continued running. It took quite a
while to finish. When I looked at the Task Manager's
Performance Screen during this operation I noted that the claim
was 63.6GB Physical Memory in use.

Things seemed to return to normal when the Check Disk run
completed. However, I noticed later that a MalwareBytes process
was now holding 63+GB private memory. I rebooted at this
point.

I understand Check Disk grabbing all the memory it could for
buffers - easier to grab then reason about reasonable behavior
- but I'm puzzled by MalwareBytes' behavior. Anyone want to
venture an opinion, informed or otherwise, about that?

A process was allocated 64 GB. Not only is that a huge
consumption by one process but you also must have something like
128 GB, or more, on the motherboard in its memory slots. There's
no way one process could suck up 64 GB of system RAM if that was
the maximum memory capacity. What motherboard are you using that
can support 128 GB, or more?

http://www.zdnet.com/article/max-mem...bit-windows-7/



I take it that you must have the Pro, Enterprise, or Ultimate edition of
Windows 7 so that OS will support more than the 16 GB max for the
Home edition. I'm still interested in what make and model
motherboard you have and what memory modules (RAM) you have in
your setup.

I am using an Asus x-79 Deluxe motherboard with G.SKILL Ripjaws Z
Series 64GB (8 x 8GB) 240-Pin DDR3 SDRAM DDR3 2400 (PC3 19200)
Desktop Memory Model F3-19200CL10Q2-64GBZHD. As I said above, I'm
running Win 7 PRO SP1 64 bit. Your assumption about what a process
can suck up is incorrect.

Thanks for the info about your hardware and Win7 edition. You
aren't running multiple concurrently active (on-demand aka realtime)
anti- malware programs, right?

How could a process while running under an OS suck up all the memory
so the OS has no memory? As Paul mentioned, a process can suck up a
lot of memory but there still has to be some for the OS.

Although I've tried several products from Malwarebytes, I gave up on
all of them. They all have slowed my computer more than other
similar security programs. Anything you add for security will slow
the computer but it shouldn't be significant or prolonged. Security
software is to protect the computer, not the primary use of the
computer.

Malwarebytes Update Released to Fix High CPU & Memory Usage in
Mbamservice.exe
https://www.bleepingcomputer.com/new...amservice-exe/


(January 27, 2018)

Looks like Malwarebytes ****ed up. Have you tried the new update?
I didn't bother to check if it is actually available or if
Malwarebytes is just making an announcement.

I tried to update after reading your comments but was told I'm running
the latest. I'm running ESET NOD32 AV in addition to MB AM. I think
there are problems with both but I've been well-protected for their
tenure so I'm loath to change anything for a while. I'm also loath to go
away from Windows since things like UNIX derivatives take so much more
work (compiling, making, etc.); it's sort of like masturbation without
the fun. I had one of the first PDP 11 machines way back when. C and
UNIX were both icon and pathetic even then.

Pardon the digression. Note that I have swap space in addition to RAM.
However, Check Disk needs buffer space and that in theory shouldn't be
swapped. I think that both Check Disk and MalwareBytes are off the
rails: Check Disk probably gained nothing by using more than a few
dozens of megabytes and MB just has coding bugs apparently. I think
Microsoft's mistake is more egregious since I expect an OS writer to be
aware of trade offs in memory utilization. Isn't making such trade offs
in allocations one of the main OS tasks?
--
Jeff Barnett

Jeff Barnett wrote:

VanguardLH wrote:

Malwarebytes Update Released to Fix High CPU & Memory Usage in
Mbamservice.exe
https://www.bleepingcomputer.com/new...amservice-exe/
(January 27, 2018)

Looks like Malwarebytes ****ed up. Have you tried the new update?

I tried to update after reading your comments but was told I'm running
the latest.

They also suggested uninstalling and reinstalling. Apparently the
current instance can interfere with obtaining the new update. For me,
if a normal update didn't work, I'd do the uninstall, follow with
remnant registry and file cleanup, and then do the reinstall. You could
use Revo Uninstaller with its medium aggressive cleanup but I'm pretty
good at remnant cleanup of the registry and file system (but that's not
to say that I haven't shot myself in my computer's foot a couple times
but backups saved my ass for those times).

Jeff Barnett wrote:
The question: What on Earth would you do with a 64GB memory?

Read on for the answer!

Years ago on a newsgroup comp.os...dos4 or somesuch, there was a long
discussion on what could one possibly do with 4MB of RAM, the best
suggestions then was to use any excess as a ramdisk. Moore's law in
action!

In message , VanguardLH
writes:
[]
Anything you add for security will slow the computer but it shouldn't
be significant or prolonged. Security software is to protect the
computer, not the primary use of the computer.
[]
Added (with attribution) to my quotes file.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Veni, Vidi, VO5 (I came, I saw, I washed my hair) - Mik from S+AS Limited
), 1998

In message , mechanic
writes:
Jeff Barnett wrote:
The question: What on Earth would you do with a 64GB memory?

Read on for the answer!

Years ago on a newsgroup comp.os...dos4 or somesuch, there was a long
discussion on what could one possibly do with 4MB of RAM, the best
suggestions then was to use any excess as a ramdisk. Moore's law in
action!

IT was ever thus (I meant to type "It", but it came out IT - which is
also appropriate!): I think it's attributed to Bill Gates "no-one will
ever need more than 640K of memory", or words to that effect, and before
that, "wonderful invention this telephone: I can see a time when every
town will have one" (or similar).
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Veni, Vidi, VO5 (I came, I saw, I washed my hair) - Mik from S+AS Limited
), 1998

In message , Jeff Barnett
writes:
[]
I'm also loath to go
away from Windows since things like UNIX derivatives take so much more
work (compiling, making, etc.); it's sort of like masturbation without
the fun.
I was tempted to add that to my quotes file too, just can't be bothered
with the comeback (-:
I had one of the first PDP 11 machines way back when. C and UNIX were
both icon and pathetic even then.
I know what you mean about "icon". At that time (around 1980 for me),
among the high priesthood, any criticism of C was just not tolerated.
(Although I don't remember thinking UNIX was any worse than any of the
alternatives we had then - I forget what those were.)
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Veni, Vidi, VO5 (I came, I saw, I washed my hair) - Mik from S+AS Limited
), 1998

On Sat, 27 Jan 2018 17:41:06 -0500, Nil
wrote in


I would call that a bug. I've already lost confidence in Malwarebytes
Anti-Malware, so this just adds to my gripe list.

Just curious and willing to consider alternatives. What are you using
in place of MBAM?
--
Web based forums are like subscribing to 10 different newspapers
and having to visit 10 different news stands to pickup each one.
Email list-server groups and USENET are like having all of those
newspapers delivered to your door every morning.