I'm not familiar with that program. You need whatever gives you the current virtual memory mappings.
Both these programs use the same counters and definitions, as they were made by the same people(Sysinternals). Which counter is it that you see multiply? You need to be more specific, because the definition of these terms vary from program to program.
VMMAP can do that, but it's still not clear to me which type of memory you see multiplying. Windows distinguishes between reserved and committed memory, and if the reserved memory keeps growing without the commit charge following, then it's a memory leak, because the application is reserving memory that is never used. If, on the other hand, the commit charge follows the amount of reserved memory with the working set being stable, then something else in the system must be memory intensive, causing the balance manager to trim the working set of CM. In any case, it must be a memory leak when the application runs out of address space without even utilizing a quarter of available RAM! That is just common sense.
No, not in the narrow sense of defining a memory leak. Just because you use a lot of memory, even if you are wasteful, doesn't mean you lost track of allocated memory.
Well, you refuse to tell me which counter you are referring to, which means it is quite impossible to know what you are talking about, or indeed that you *know* what you are talking about
It's not my fault that Microsoft and related companies make a mess out of designations for standard kinds of memory. The virtual address space is a hardware feature from the MMU so it isn't different OS concepts that apply here. It's just people trying to be cute and making up their own names for an audience who they assume doesn't know the hardware.Well, you refuse to tell me which counter you are referring to, which means it is quite impossible to know what you are talking about, or indeed that you *know* what you are talking about
I think it would be wrong to blame Microsoft for not having the "right" definition for something that it is not at all clear how one should define. Memory management is a lot more complicated than physical versus virtual memory. And the people who made PE are also Microsoft, might I remind you.
Sure it is. Everybody uses the same terms except the microsofts. I mean they even call swapspace "virtual memory" in some consumer-facing programs for crying out loud. (luckily the developer docs don't repeat that mistake)
Yes, my impression is that it's the "newer" cards that are problematic. I remember having perfomance issues the first time around 2008; after a graphics card upgrade, I would get 10 fps with the 'Al Huqf' scenario. Before that, things were really smooth. The game is still living in 2007, I think.
Once you've gotten used to 60 fps, your eyes will bleed when going below.
Which program is this?
Except that there is. There is shared memory, private memory, locked memory, guarded memory, reserved memory, committed memory, paged memory, non-paged memory, kernel memory, user memory ... the list goes on. Sorry, but it's clear that you don't know much what you are talking about when you oversimplify things into virtual vs. physical memory. It's not at all clear what should be included in a general 'virtual memory' performance counter, and it's not at all clear what you are talking about when you're trying to make a point about CM running out of "virtual memory" and not "physical memory".
I suppose I should have mentioned it's Win8 32bit.
Uh? The default task manager uses the term "virtual memory" for swapspace. That's complete BS and obviously has been decided by somebody at Microsoft who doesn't understand virtual memory and wanted to make up a cute term for the average user. Luckily most of the programmer-facing microsoft documentation isn't affected by this.
So I just fired up process explorer and the value you need is simply called "Virtual size". I really don't know where your confusion comes from. We are at the point now where I have to question whether we have a serious discussion here.
Sorry, but this is just foolish anti-Microsoft attitude. No, the task mananger shows the private part of the commit charge afaics, which is something entirely different than "swapspace". This is a quite natural number, and it is not given that they should have picked the number you want.
Redwolf, this discussion started with you making a point about CM not running out of physical but Virtual Memory. You then pointed me to Process Explorer because it allegedly showed the "right" number. Then you wouldn't tell me which number it was. I suspect this is because you have NO idea what the 'Virtual Size' counter really indicates.
Very sorry but all that matters for the crash is the sum of memory mapping, which process explorer gives as "virtual size". It matters not whether any of it is shared and it matters not how much of it is currently backed by physical pages.Sorry, but this is just foolish anti-Microsoft attitude. No, the task mananger shows the private part of the commit charge afaics, which is something entirely different than "swapspace". This is a quite natural number, and it is not given that they should have picked the number you want.
Redwolf, this discussion started with you making a point about CM not running out of physical but Virtual Memory. You then pointed me to Process Explorer because it allegedly showed the "right" number. Then you wouldn't tell me which number it was. I suspect this is because you have NO idea what the 'Virtual Size' counter really indicates.
So let me tell you: The 'Virtual Size' counter is an indicator of virtual memory usage, but unlike the task manager 'Virtual memory', it includes reserved and shared memory also. That means you also have memory that is not mapped(used) and memory that is shared between other processes. The concept of 'reserved memory' is something Windows uses to allow you to reserve large portions of contiguous memory for future use, usually for performance reasons, without it being mapped to a backing store("swapspace"). Very fast and efficient. And like I explained earlier: If the process keeps increasing its 'Virtual size' counter out of proportion to the working set(physical memory), that means you have a lot of reserved memory allocated through the VirtualAlloc system call that never gets committed. A classic indication of a memory leak, indeed. Thus the amount of physical memory(working set) used is VERY important for what we are talking about, and so is the commit charge. This is why I asked you about the counters and why your statements are too general.
Oh, boy - why do you keep insisting on your own flawed conceptions of this? The 'Virtual Size' is not mapped memory - that is precisely what reserved memory is not. It's not mapped to any backing store, RAM or swapspace, at all. If you want the 'the sum of memory mapping' you would want to look at the commit charge or 'Private Bytes' counter.
HAHAHA. *Laughing hard*! I think you've made it clear now that you DO in fact believe in Satan(Microsoft).
Hahaha, no. The only thing that really made me confused was you giving the impression you were tech savvy. The 700MB and then going KABOOM is what you claim - I haven't observed that at all. And given that you don't know the difference between reserved and committed memory, and indeed that you believe memory management implementation is the same everywhere because "the MMU is the same", means I'm certainly not going to take your word for it.
You can't. But we would have a much better discussion about what's going on than what we had in the last days
