gamerk316 :
as you open programs it looks at the commit charge to see if it has
the address space to open the program
That would be true, except that every program gets its own unique 2GB Virtual Address space when a process is created. So its NOT an Address Space problem. Well...maybe if the pagefile is too small...[try setting a VERY large pagefile, just for kicks. Very little reason to ever turn it from System Managed though...]
I've seen this happen in XP, and never really found out why. First I've heard of it occuring in 7 though. Could be something as simple as process priorities getting messed up. [Windows is priority based; the thread with teh highest priority ALWAYS runs. If the OS kernal is doing something in the background, it could preempt everything, evne program start up, and wouldn't show in Task Manager to boot. Problem is, I have no idea what could cause that behavior in the first place if thats indeed the case...]
ok bear with me I am still learning
I will have to read this 3 times just to start to understand
sorry for the big post
this is cut from Wikipedia
Commit charge
From Wikipedia, the free encyclopedia
In computing, commit charge is a term used in Microsoft Windows operating systems to describe the total amount of pageable virtual address space for which no backing store is assigned other than the pagefile. On systems with a pagefile, it may be thought of as the maximum potential pagefile usage. On systems with no pagefile, it is still counted, but all such virtual address space must remain in physical memory (RAM) at all times.
[edit] Overview
The Windows Task Manager utility, in its Performance tab, shows three counters related to commit charge:
Total is the amount of pagefile-backed virtual address space in use, i.e., the current commit charge. This is composed of main memory (RAM) and disk (pagefiles). The corresponding performance counter is called "Committed Bytes".
Limit is the maximum possible value for Total; it is the sum of the current pagefile size plus the physical memory available for pageable contents (this excludes RAM that is assigned to non-pageable areas). The corresponding performance counter is called "Commit Limit".
Peak is the highest amount that the total commit charge has reached since the operating system was last started.
The program Process Explorer reports the same set of values, labeling the Total as Current, and additionally providing percentages of Peak and Current towards the Limit value.
The commit charge increases when any program is opened and used, and goes down when a program is closed. It will also change when already-running programs allocate or free private virtual memory; for example, with the VirtualAlloc and VirtualFree APIs.
In the Task Manager utility under Windows XP and Windows Server 2003, the graphical displays labeled "PF usage" and "Page File Usage History," despite their labels, reflect not the pagefile contents but the total (or current) commit charge. The height of the graph area corresponds to the commit limit. These do not show how much has actually been written to the pagefile, but only the maximum potential pagefile usage: The amount of pagefile that would be used if all current contents of RAM had to be removed. In Windows 2000 and Windows NT 4.0, these same displays are labeled "Mem usage" but again actually show the commit charge and commit limit. Similar displays in the Task Manager of Windows Vista and later have been changed to reflect usage of physical memory.
In Task Manager's "Processes" display, each process's contribution to the "total commit charge" is shown in the "VM size" column in Windows XP and Server 2003. The same value is labeled "Commit size" in Windows Vista and later. The total commit charge will always be larger than the sum of these values, as the total includes system-wide allocations such as the paged pool.
In the same display, the "Mem Usage" column in Windows XP and Server 2003, or the "Working Set (Memory)" column in Windows Vista and later, shows each process's current working set. This is a count of physical memory (RAM) rather than virtual address space. It represents the subset of the process's virtual address space that is valid, meaning that it can be referenced without incurring a page fault.
The commit charge for each process does not include other major contributions to the process's virtual address space, such as mapped files. For this reason, the process's working set (the portion of its address space that can be referenced without incurring a page fault) may be larger than its contribution to total commit charge, and the total commit charge is not inclusive of the total memory (physical or virtual) actually in use.
The commit limit may be increased by either creating additional pagefiles or, if pagefile expansion is enabled, by expanding an existing one. The operating system will expand the pagefile automatically, if possible, when the total commit charge approaches the limit. In such an event a popup window will be displayed stating that "The system is running low on virtual memory."
If the system ever runs completely out of commit charge (that is, if the total reaches the limit), a popup window will be displayed stating that "The system is out of virtual memory," and it may become extremely sluggish or even nonresponsive. Closing programs (if the user is still able to do so at this point) decreases the total commit charge and may thereby free up the system
for some Toms members this may be Memory Addressing 101 LOL
so if they can help explain it in ENGLISH
that would be great
from what I can understand by not having a pagefile than you are limited to the the amount of ram you have
for your commit limit
if your commit limit is exceeded then you will have an out of virtual memory error
I have to research what a page fault is and what problems that causes
Of course the point is moot now since it sounds like a RAM error was possibly causing problem
though Enzo said this
I can't figure out why, but removing the pagefile or moving the page file to a drive other than my C: (vertex 2) solves the issue
the key to the problem lies in that statement
Facebook
Twitter
Instagram