Re: System pretends to be out of memory when it isn't

The problem is showing up at this moment. Included in this batch of
symptoms:

1. I didn't have any menu options in Outlook Express until I closed a
network folder window.

2. Hitting "reply to group" generated an error of "not enough memory" until
I closed one of two open session windows that were open in GAIM.

The performance tab in task manager is blank again, but I can see 57
processes, 5% CPU usage, and commit charge of 481M / 2928M in the lower
status border.

msinfo32.exe would not open until I shut down the google desktop search; the
IRQ table was previously posted.

14632 handles, 616 threads, 53 processes


"R. McCarty" <PcEngWork-NoSpam_@xxxxxxxxxxxxxx> wrote in message
news:eVi1qY3%23FHA.208@xxxxxxxxxxxxxxxxxxxxxxx
> One more information request, Can you run MSInfo32.Exe, expand
> the Hardware category, IRQs and export the IRQ Table map to a Txt
> file and include the contents in a follow-up post ?
>
> "Wowbagger" <none> wrote in message
> news:ulvWzR3%23FHA.2424@xxxxxxxxxxxxxxxxxxxxxxx
>>I had to reboot - after restarting I am showing minimum 101.995, max
>>552.960 with average hovering around 180 i/sec
>>
>> I have one IDE hard drive, one IDE CD burner and one IDE DVD burner, both
>> of which only get occasional use. (burn maybe 4 disc every few months).
>>
>> "R. McCarty" <PcEngWork-NoSpam_@xxxxxxxxxxxxxx> wrote in message
>> news:%23f5ajE3%23FHA.916@xxxxxxxxxxxxxxxxxxxxxxx
>>> Using Perfmon.Msc, what does your CPU Interrupt count show ?
>>> Also what, how many and which interface type are your disk drives ?
>>>
>>> "Wowbagger" <none> wrote in message
>>> news:urketB3%23FHA.2324@xxxxxxxxxxxxxxxxxxxxxxx
>>>> The computer is showing the behavior at this moment:
>>>>
>>>> Running applications: Outlook, Gaim, MusicMatch.
>>>>
>>>> I was renaming photos on my desktop and copying them across the network
>>>> to the server. With 1Gb of memory I can usually copy dozens of photos
>>>> simultaneously without issue, but if I select more than a dozen or so
>>>> the cut/paste simply does not work. I clicked on the shortcut for
>>>> Outlook Express and am told that the application has moved or otherwise
>>>> can't be found. I close Outlook (2003) and the OE shortcut starts to
>>>> work again.
>>>>
>>>> I CTRL-ALT-DEL into task manager and have three tabs instead of the
>>>> usual four (the network tab is missing) and all three tabs -
>>>> applications, processes and performance are completely blank. I close
>>>> music match and the process tab but not the performance tabs is
>>>> displaying properly, though some of the text is weirdly flickering
>>>> (I've never seen this before).
>>>>
>>>> 50 Processes
>>>> CPU Usage holding steady at 7%
>>>> Commit Charge: 384M / 2928M
>>>>
>>>> I close down the google desktop search and the performance tab starts
>>>> to show.
>>>>
>>>> Handles: 12235
>>>> Threads: 581
>>>> Processes: 46
>>>>
>>>> Commit Charge (K)
>>>> Total 370640
>>>> Limit 2998464
>>>> Peak 742480
>>>>
>>>> Physical Memory (K)
>>>> Total 1046528
>>>> Available 620988
>>>> System Cache 674284
>>>>
>>>> Kernel Memory (K)
>>>> Total 85312
>>>> Paged 58656
>>>> Nonpaged 26656
>>>>
>>>>
>>>> "David Candy" <.> wrote in message
>>>> news:%238jkOF1%23FHA.1028@xxxxxxxxxxxxxxxxxxxxxxx
>>>> It was one thing I was looking at earlier
>>>>
>>>> Umdhtools.exe: How to Use Umdh.exe to Find Memory Leaks
>>>>
>>>> Q268343
>>>>
>>>>
>>>> --------------------------------------------------------------------------------
>>>> The information in this article applies to:
>>>>
>>>> a.. Microsoft Windows 2000 Advanced Server
>>>> b.. Microsoft Windows 2000 Server
>>>> c.. Microsoft Windows 2000 Professional
>>>> d.. Microsoft Windows NT Server version 4.0
>>>> e.. Microsoft Windows NT Workstation version 4.0
>>>>
>>>> --------------------------------------------------------------------------------
>>>>
>>>>
>>>> SUMMARY
>>>> The user-mode dump heap (UMDH) utility works with the operating system
>>>> to analyze Windows heap allocations for a specific process. This
>>>> utility, and the other tools associated with it, are primarily targeted
>>>> for Windows 2000. However, a Umdh_nt4.exe application, and the
>>>> Dbghelp.dll which is not available on Windows NT, have been supplied
>>>> for use under Windows NT version 4.0 Service Pack 6 (SP6). This article
>>>> discusses how you can use UMDH to help locate memory leak problems. A
>>>> self-extracting executable is included that contains the following
>>>> tools:
>>>>
>>>> a.. Umdh.exe- This utility is used to dump the heap allocation
>>>> information for a process.
>>>>
>>>>
>>>> b.. Umdh_nt4.exe and Dbghelp.dll - This is the Windows NT 4.0 SP6
>>>> version of the UMDH tool.
>>>>
>>>>
>>>> c.. Gflags.exe- This utility sets the appropriate registry entries for
>>>> the application that will be analyzed. The operating system looks at
>>>> the registry entries to determine if an application's heap allocations
>>>> will be tracked.
>>>>
>>>>
>>>> d.. Tlist.exe - This application lists all of the processes running on
>>>> a machine and all of their related process IDs.
>>>>
>>>>
>>>> e.. Dhcmp.exe - This tool is used to compare two UMDH dumps to
>>>> determine where a possible memory leak is occurring.
>>>>
>>>>
>>>> f.. Dhcmpgui.zip - This tool also compares two UMDH logs but has a
>>>> user interface to make it easier to retrieve information. The .zip file
>>>> contains the Dhcmpgui.exe file and its source code.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> MORE INFORMATION
>>>> The following file is available for download from the Microsoft
>>>> Download Center:
>>>>
>>>>
>>>>
>>>> Umdhtools.exe
>>>> Release Date: Feb. 5, 2001
>>>>
>>>> For additional information about how to download Microsoft Support
>>>> files, click the article number below to view the article in the
>>>> Microsoft Knowledge Base:
>>>> Q119591 How to Obtain Microsoft Support Files from Online Services
>>>> Microsoft used the most current virus detection software available on
>>>> the date of posting to scan this file for viruses. Once posted, the
>>>> file is housed on secure servers that prevent any unauthorized changes
>>>> to the file.
>>>>
>>>>
>>>> Before Using UMDH
>>>> If you think you are experiencing a memory leak, please be aware that
>>>> memory leaks may not be what they appear to be. You may discover that a
>>>> memory leak is really not a memory leak but a performance enhancement.
>>>> For example, the Microsoft Jet database engine can consume large
>>>> amounts of memory (up to 128 MB on a 256-MB computer) for its data
>>>> retrieval and writing caches. The cache allows the Jet engine to
>>>> achieve fast read-ahead and write-ahead buffering.
>>>>
>>>> To determine whether or not a process is experiencing memory leaks, use
>>>> Windows Performance Monitor (Perfmon.exe) and monitor "Private Bytes"
>>>> under the Process category for your application. Privates Bytes is the
>>>> total amount of memory the process has allocated but is not sharing
>>>> with other processes. Note that this is different from "Virtual Bytes,"
>>>> which is also interesting to monitor. Virtual Bytes is the current size
>>>> in bytes of the virtual address space the process is using. An
>>>> application can leak virtual memory but not see a difference in the
>>>> amount of private bytes allocated. If you don't see memory rising when
>>>> monitoring private bytes but suspect that you are still running out of
>>>> memory, you should monitor virtual bytes to see if you are exhausting
>>>> virtual memory.
>>>>
>>>> Review the following MSDN article titled "Finding Leaks and Bottlenecks
>>>> with a Windows NT PerfMon COM Object" for more information about
>>>> detecting memory leaks:
>>>> http://msdn.microsoft.com/library/techart/perfmon.htm
>>>> To be certain your application is leaking memory, you should place the
>>>> suspect code in a loop with many iterations, and monitor private and
>>>> virtual bytes for any increases of memory. Watch to make certain that
>>>> the number of private bytes and virtual bytes doesn't eventually stay
>>>> the same and stops rising. If there is a point at which the memory
>>>> stops rising, that is, it does not continue to climb indefinitely, you
>>>> are not seeing a memory leak but are probably seeing some cache that is
>>>> growing to its maximum size.
>>>> Capturing Heap Dumps with UMDH
>>>> UMDH (or Umdh_nt4.exe if you are using Windows NT 4.0 SP6) is a tool
>>>> that dumps information about a process's heap allocations. This
>>>> information includes the callstack for each allocation, the number of
>>>> allocations made through that callstack, and the number of bytes
>>>> consumed through that callstack. For example:
>>>>
>>>> 00005320 bytes in 0x14 allocations (@ 0x00000428) by: BackTrace00053
>>>> ntdll!RtlDebugAllocateHeap+0x000000FD
>>>> ntdll!RtlAllocateHeapSlowly+0x0000005A
>>>> ntdll!RtlAllocateHeap+0x00000808
>>>> MyApp!_heap_alloc_base+0x00000069
>>>> MyApp!_heap_alloc_dbg+0x000001A2
>>>> MyApp!_nh_malloc_dbg+0x00000023
>>>> MyApp!_nh_malloc+0x00000016
>>>> MyApp!operator new+0x0000000E
>>>> MyApp!LeakyFunc+0x0000001E
>>>> MyApp!main+0x0000002C
>>>> MyApp!mainCRTStartup+0x000000FC
>>>> KERNEL32!BaseProcessStart+0x0000003D This UMDH output shows that
>>>> there were 21280 (0x5320) bytes allocated total from the callstack. The
>>>> 21280 bytes were allocated from 20 (0x14) separate allocations of 1064
>>>> bytes (0x428). The callstack is given a identifier of BackTrace00053.
>>>>
>>>> To produce a dump of the heap allocations, you must first let the
>>>> operating system know that you would like the kernel to track the
>>>> allocations. This is done by using the Gflags.exe utility.
>>>>
>>>> Let's assume that you want to dump the heap contents for Notepad.exe.
>>>> By the way, most processes have more than one heap active and the UMDH
>>>> log will contain all of them. First you need to enable stack trace
>>>> acquisition for the application you want to test. This feature is not
>>>> enabled by default. The command to enable it is:
>>>> gflags -i notepad.exe +ust
>>>> The command does not enable stack tracing for processes that are
>>>> already running, but all future executions of Notepad.exe will have it
>>>> enabled. Alternatively, you can set the flag through the GFLAGS user
>>>> interface (run Gflags.exe without any arguments to get the user
>>>> interface). Before using UMDH, you also need to install the correct
>>>> debug symbols for the components of your application as well as the
>>>> operating system. Typically, the operating system symbols are installed
>>>> in the SYMBOLS folder on the WINNT folder. UMDH attempts to find the
>>>> symbol files by using the _NT_SYMBOL_PATH. The command for setting the
>>>> path from a command prompt is:
>>>> set _NT_SYMBOL_PATH=%windir%\symbols
>>>> For more information about setting up symbolic debugging information,
>>>> see the "Debug Symbols" section later in this article.
>>>>
>>>> With the image flags set and the symbols installed, you are ready to
>>>> start Notepad. After the program is started, you need to determine the
>>>> Process ID (PID) of the Notepad process just started. The command for
>>>> this is:
>>>> tlist
>>>> You can find the PID from the output of the TLIST application. The PID
>>>> information can also be obtained from Task Manager. Let's assume the
>>>> PID for the Notepad process you just started is 124. You can use UMDH
>>>> to get a heap dump by using the following command:
>>>> umdh -p:124 -f:notepad124.log
>>>> Results: You've got a complete heap dump of the Notepad process in the
>>>> Notepad124.log file.
>>>> Using Dhcmp.exe to Compare UMDH Logs
>>>> While the UMDH log file contains valuable information about the current
>>>> state of the heaps for a process, if you are concerned with finding a
>>>> memory leak, it may be more valuable to compare the outputs of two logs
>>>> and find out what callstack has seen the largest growth between the two
>>>> dumps. The Dhcmp.exe utility helps compare two UMDH logs to provide an
>>>> analysis of the difference between them. Once you have two logs
>>>> captured at different intervals, you can then use the following
>>>> command:
>>>> DHCMP dh1.log dh2.log > cmp12.txt
>>>> The .txt files will compare the effect on memory of running the suspect
>>>> memory hog application. The output of the file generated by DHCMP
>>>> resembles the following:
>>>>
>>>> + 5320 ( f110 - 9df0) 3a allocs BackTrace00053
>>>> Total increase == 5320 For each BackTrace in the UMDH log files, there
>>>> is a comparison made between the two logs files. This case shows that
>>>> the last log file specified in the DHCMP command line had F110 bytes
>>>> allocated while the first log in the DHCMP command line had 9DF0 bytes
>>>> allocated for the same BackTrace (callstack). The 5320 is the
>>>> difference in the number of bytes allocated. In this case, there were
>>>> 5320 more bytes allocated between the time the two logs were captured.
>>>> The bytes came from the callstack identified by BackTrace00053.
>>>>
>>>> The next step is to find out what's in that backtrace. If you open the
>>>> second DH log file and search for "BackTrace00053" you might find
>>>> something that resembles the following:
>>>>
>>>> 00005320 bytes in 0x14 allocations (@ 0x00000428) by: BackTrace00053
>>>> ntdll!RtlDebugAllocateHeap+0x000000FD
>>>> ntdll!RtlAllocateHeapSlowly+0x0000005A
>>>> ntdll!RtlAllocateHeap+0x00000808
>>>> MyApp!_heap_alloc_base+0x00000069
>>>> MyApp!_heap_alloc_dbg+0x000001A2
>>>> MyApp!_nh_malloc_dbg+0x00000023
>>>> MyApp!_nh_malloc+0x00000016
>>>> MyApp!operator new+0x0000000E
>>>> MyApp!LeakyFunc+0x0000001E
>>>> MyApp!main+0x0000002C
>>>> MyApp!mainCRTStartup+0x000000FC
>>>> KERNEL32!BaseProcessStart+0x0000003D By looking at the
>>>> callstack, you can see that the LeakyFunc function is allocating memory
>>>> by way of the Visual C++ run-time library. If you find that the number
>>>> of allocations grows as you took more dumps, you might be able to
>>>> conclude that memory is not being freed.
>>>> Enabling Stack Traces
>>>> The most important information in UMDH logs is the stack traces of the
>>>> heap allocations. By analyzing them it can be understood whether a
>>>> process leaks heap memory. These stack traces are not acquired by
>>>> default. The feature can be enabled per-process or system-wide. Use the
>>>> following command to enable stack tracing system-wide:
>>>> gflags -r +ust
>>>> Restart the computer after this command.
>>>>
>>>> For per-process enabling, the command is
>>>> gflags -i APPNAME +ust
>>>> Where APPNAME is the file name of the executable including the
>>>> extension (Services.exe, lsass.exe, and so on). The command will not
>>>> enable stack tracing for a process that is already running. For this
>>>> reason, in the case of processes that can't be restarted (services,
>>>> lsass, winlogon), the test compute must be restarted.
>>>>
>>>> Use the following commands to verify what settings have been set
>>>> system-wide or for a specific process:
>>>>
>>>> System-wide:
>>>> gflags -r
>>>> Specific process:
>>>> gflags -i APP-NAME
>>>> By default, the maximum stack trace depth is 16. If you want to see
>>>> deeper callstacks, you can increase this by running GFLAGS. Click to
>>>> select System Registry and type a new depth in the Max. Stack Trace
>>>> Capture Depth edit control. Click Apply, and then restart the computer.
>>>>
>>>> IMPORTANT: If you are using Windows NT 4.0 Service Pack 6, you must use
>>>> Umdh_nt4.exe, rather than Umdh.exe, and you must use the above command
>>>> to set system-wide stack tracing. Be certain to reboot. Umdh_nt4 stack
>>>> tracing does not work on a per process basis on Windows NT version 4.
>>>> It must be set for the entire system.
>>>> Debug Symbols
>>>> UMDH uses the IMAGEHLP library for symbol manipulation. This is the
>>>> standard tool for such tasks and it is also used by Microsoft
>>>> debuggers. One of the most important steps to using UMDH is to ensure
>>>> that you have good symbol files (.dbg or .pdb file) to get a good stack
>>>> trace. The debug symbol files can be installed from the Windows NT CD,
>>>> or in the case of Microsoft Windows 2000, from the Windows 2000 Support
>>>> Tools CD. At a minimum, you need the Kernel32.dbg and Ntdll.dbg symbol
>>>> files. You can always acquire additional debugging symbols as needed as
>>>> you find out more about which components are leaking the memory.
>>>>
>>>> When building components with Visual C++, it is important that you not
>>>> have Program Database for Edit and Continue selected for the C++
>>>> compiler options. Instead, select Program Database.
>>>>
>>>> To set the symbol path, initialize the _NT_SYMBOL_PATH environment
>>>> variable to the path to be used. This can be done once when the test
>>>> computer is set up by using the System application in Control Panel
>>>> (Advanced, Environment Variables) or inside a command window before
>>>> UMDH is run. Usually the symbols are copied to the test machine in the
>>>> %windir%\Symbols folder. In this case, use the following command to set
>>>> the variable:
>>>> set _NT_SYMBOL_PATH=%windir%\symbols
>>>> NOTE: Include the path to the PDBs for your application's components as
>>>> well.
>>>> Invoking UMDH
>>>> The only required command-line parameter for UMDH is the -p option,
>>>> which specifies the PID of the process from which a heap dump will be
>>>> obtained. The PID can be obtained by using Task Manager or the
>>>> Tlist.exe program. For a command similar to the following, the log will
>>>> be dumped to the standard output:
>>>> umdh -p:PID
>>>> UMDH also displays various informational messages to standard error,
>>>> and therefore if not redirected it will be mixed with the real log. To
>>>> gather the UMDH informational messages in a file, use the following
>>>> command:
>>>> umdh -p:PID 2>umdh.msg
>>>> If you want to gather the log dumped by UMDH in a file, use one of the
>>>> following commands:
>>>> umdh -p:PID >umdh.log
>>>> -or-
>>>>
>>>> umdh -p:PID -f:umdh.log
>>>> The commands are completely equivalent.
>>>>
>>>> The default log obtained by UMDH contains an enumeration of heap
>>>> consumers sorted by allocation count. If, for debugging purposes, you
>>>> also need a dump of all allocated blocks with their corresponding stack
>>>> traces, the -d option must be used:
>>>> umdh -p:PID -d
>>>> If the log contains too much information, it can be limited only to big
>>>> users that have the allocation count above a certain threshold. Use the
>>>> following command:
>>>> umdh -p:PID -t:THRESHOLD
>>>> All the command-line options (-p, -f, -t, -d) can be specified
>>>> simultaneously in any order. Following is a complicated command-line
>>>> example:
>>>> umdh -p:123 -t:1000 -f:umdh.log -d
>>>> This command dumps the heaps for the process with PID 123 into the
>>>> Umdh.log file. It dumps only stack traces that account for more than
>>>> 1000 allocations and it also dumps the addresses of the heap blocks
>>>> allocated through each stack trace.
>>>> UMDH Output Explained
>>>> If you redirected the log to a file (umdh -p:PID -f:umdh.log), the
>>>> contents will resemble the following, which was obtained from a running
>>>> Notepad process:
>>>>
>>>> UMDH: Logtime 2000-06-28 10:54 - Machine=MYMachine - PID=704
>>>> *********** Heap 00270000 Information ********************
>>>> Flags: 58000062
>>>> Number Of Entries: 87
>>>> Number Of Tags: <unknown>
>>>> Bytes Allocated: 00008DF0
>>>> Bytes Committed: 0000A000
>>>> Total FreeSpace: 00001210
>>>> Number of Virtual Address chunks used: 1
>>>> Address Space Used: <unknown>
>>>> Entry Overhead: 8
>>>> Creator: (Backtrace00007)
>>>> ntdll!RtlDebugCreateHeap+0x00000196
>>>> ntdll!RtlCreateHeap+0x0000023F
>>>> ntdll!LdrpInitializeProcess+0x00000369
>>>> ntdll!LdrpInitialize+0x0000028D
>>>> ntdll!KiUserApcDispatcher+0x00000007
>>>> *********** Heap 00270000 Hogs ********************
>>>> 000001A0 bytes in 0x4 allocations (@ 0x00000068) by: BackTrace00031
>>>> ntdll!RtlDebugAllocateHeap+0x000000FB
>>>> ntdll!RtlAllocateHeapSlowly+0x0000005B
>>>> ntdll!RtlAllocateHeap+0x00000D81
>>>> ntdll!LdrpAllocateDataTableEntry+0x00000039
>>>> ntdll!LdrpMapDll+0x000002A4
>>>> ntdll!LdrpLoadImportModule+0x0000010D
>>>> ntdll!LdrpWalkImportDescriptor+0x0000008B
>>>> ntdll!LdrpLoadImportModule+0x0000011D
>>>> ntdll!LdrpWalkImportDescriptor+0x0000008B
>>>> ntdll!LdrpLoadImportModule+0x0000011D
>>>> ntdll!LdrpWalkImportDescriptor+0x0000008B
>>>> ntdll!LdrpInitializeProcess+0x000009DC
>>>> ntdll!LdrpInitialize+0x0000028D
>>>> ntdll!KiUserApcDispatcher+0x00000007
>>>>
>>>> 000001A0 bytes in 0x4 allocations (@ 0x00000068) by: BackTrace00034
>>>> ntdll!RtlDebugAllocateHeap+0x000000FB
>>>> ntdll!RtlAllocateHeapSlowly+0x0000005B
>>>> ntdll!RtlAllocateHeap+0x00000D81
>>>> ntdll!LdrpAllocateDataTableEntry+0x00000039
>>>> ntdll!LdrpMapDll+0x000002A4
>>>> ntdll!LdrpLoadImportModule+0x0000010D
>>>> ntdll!LdrpWalkImportDescriptor+0x0000008B
>>>> ntdll!LdrpLoadImportModule+0x0000011D
>>>> ntdll!LdrpWalkImportDescriptor+0x0000008B
>>>> ntdll!LdrpLoadImportModule+0x0000011D
>>>> ntdll!LdrpWalkImportDescriptor+0x0000008B
>>>> ntdll!LdrpLoadImportModule+0x0000011D
>>>> ntdll!LdrpWalkImportDescriptor+0x0000008B
>>>> ntdll!LdrpInitializeProcess+0x000009DC
>>>> ntdll!LdrpInitialize+0x0000028D
>>>> ntdll!KiUserApcDispatcher+0x00000007 The log contains a dump of
>>>> every heap in the process. In this example, the log starts with a heap
>>>> at address 270000. After a few global counters for the heap, the log
>>>> contains a dump in decreasing sorted order of stack traces that are
>>>> responsible for the most allocations. By comparing the dynamics of
>>>> memory used at different moments you can deduce what happened in the
>>>> process and if any heap use looks like a leak.
>>>> Problems That Can Be Encountered When Using UMDH
>>>> The most common errors when using UMDH are not having stack tracing
>>>> enabled. Incorrect symbols for Ntdll.dll prevent UMDH from running. For
>>>> the other symbols files, UMDH will run but the log file will contain
>>>> stack traces that do not have function names but instead have relative
>>>> addresses inside modules. A distant third error is specifying a wrong
>>>> PID. The following error message results when you attempt to run UMDH
>>>> for a process that does not have stack tracing enabled:
>>>> C:\>umdh -p:1140
>>>> UMDH: Logtime 2000-06-28 12:43 - Machine=MyMachine - PID=1140
>>>> Connecting.....Module enumeration complete.
>>>> SymGetSymFromName(process, ntdll!RtlpStackTraceDataBase, xxx) failed,
>>>> LastError = 126
>>>> UmdhGetAddrFromName couldn't find Stack Trace DB pointer
>>>> (ntdll!RtlpStackTraceDataBase).
>>>> ntdll.dll symbols are incorrect; we must be able to see non-import
>>>> symbols.
>>>> Use the following command to double-check the settings for the process
>>>> you are investigating:
>>>> gflags -i APPNAME
>>>> Use the following command in the case where you are relying on
>>>> system-wide stack tracing:
>>>> gflags -r
>>>> These commands show the list of flags set for the application. Note
>>>> that in the case of system-wide stack tracing, the feature might appear
>>>> as active but if you did not restart the computer after running the
>>>> gflags -r +ust command, it is not actually activated. If you want to
>>>> know every application that has stack tracing enabled, you can look at
>>>> the USTEnabled key under the following registry key:
>>>> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image
>>>> File Execution Options
>>>> If you run UMDH on a process that has stack tracing enabled but have
>>>> not restarted the application since setting the flags, you may get the
>>>> following message in your logs:
>>>> A stack trace was not saved for this allocation (Index == 0)
>>>> If you run UMDH without setting the correct symbol path or the symbols
>>>> are incorrect, you may get an error message in the log. However, you
>>>> may just get incorrect or misleading callstacks. To verify whether you
>>>> have the correct symbols, launch the NTSD system debugger for a
>>>> process, for example:
>>>> ntsd notepad
>>>> Then, from the debugger console, run the LD command to load the symbol
>>>> information for the module and the LM command to list what modules have
>>>> their symbols loaded. If the output of the LM command shows export
>>>> symbols loaded, the symbols are not good. If you have PDB symbols
>>>> loaded, the symbols are good. You may get the following error message
>>>> if you specified the wrong PID:
>>>> C:\>umdh -p:1000
>>>> UMDH: Logtime 2000-06-28 09:45 - Machine=MyMachine - PID=1000
>>>> Connecting...
>>>> OpenProcess failed, LastError = 0x57
>>>>
>>>> Additional Tools
>>>> Using DHCMPGUI
>>>> The Dhcmpgui.exe tool can be used to compare two UMDH logs. This tool
>>>> is located in the Dhcmpgui.zip file. It calls out to Dhcmp.exe (make
>>>> certain that you have this in your PATH). Click File 1 and File 2 to
>>>> specify the two UMDH logs to compare.
>>>>
>>>> After selecting the two files to compare, you will see a list of the
>>>> differences. The columns listed are the number of bytes allocated,
>>>> number of allocations, and the BackTraceID, respectively. You can sort
>>>> by any one of those columns by clicking the appropriate button, and
>>>> then clicking Sort. To see the BackTrace (callstack) for any line, just
>>>> double-click it. This provides an easy way to compare two logs and to
>>>> quickly get to the callstack for the callstack that is leaking memory.
>>>>
>>>> The source code has been provided for Dhcmpgui.exe in case you want to
>>>> make any modifications. The project requires Visual C++ version 6.0.
>>>> Calling UMDH from Visual Basic
>>>> There may be times when it is useful to dump a number of logs over time
>>>> because the leak may not be very noticeable at first. For example,
>>>> suppose you suspect that your ASP application is leaking memory. It may
>>>> be helpful to write a COM component in Visual Basic that shells out to
>>>> UMDH. You can then call that component from your ASP page.
>>>>
>>>> Following is some Visual Basic code that invokes UMDH and creates a log
>>>> file based on the current time:
>>>>
>>>>
>>>> Private Declare Function GetCurrentProcessId Lib "kernel32" () As
>>>> Long
>>>> Public Function GetProcessID()
>>>> GetProcessID = GetCurrentProcessId()
>>>> End Function
>>>> .
>>>> .
>>>> .
>>>> Dim strTime As String
>>>>
>>>> Dim sProcID As String
>>>> sProcID = GetProcessID()
>>>> strTime = "MYLOG_" & Format(Now(), "hhmm")
>>>>
>>>> Shell ("C:\UMDH\umdh -p:" & sProcID & " -f:d:\logs\" & strTime &
>>>> ".txt")
>>>> Additional query words: DH umDHtools dumpheap displayheap
>>>>
>>>> Keywords : kbfile kbsample kbOSWin2000 kbGrpDSVCDB kbDSupport
>>>> kbgraphxlinkcritical
>>>> Issue type : kbhowto
>>>> Technology : kbWinNTsearch kbWinNTWsearch kbWinNTW400 kbWinNTW400search
>>>> kbWinNT400xsearch kbwin2000AdvServ kbwin2000AdvServSearch kbwin2000Serv
>>>> kbWinNTSsearch kbWinNTS400xsearch kbWinNTS400 kbwin2000ServSearch
>>>> kbwin2000Search kbwin2000ProSearch kbwin2000Pro kbWinAdvServSearch
>>>>
>>>>
>>>> Last Reviewed: June 2, 2001
>>>> © 2001 Microsoft Corporation. All rights reserved. Terms of Use.
>>>>
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------------------
>>>> Send feedback to MSDN.Look here for MSDN Online resources.
>>>>
>>>> --
>>>> --------------------------------------------------------------------------------------------------
>>>> Goodbye Web Diary
>>>> http://margokingston.typepad.com/harry_version_2/2005/12/thank_you_and_g.html#comments
>>>> =================================================
>>>> "Wowbagger" <none> wrote in message
>>>> news:O5LHbH0%23FHA.272@xxxxxxxxxxxxxxxxxxxxxxx
>>>>> Yeah... I'd thought of that too, but the problem with that is that I'd
>>>>> have
>>>>> to wait hours (sometimes days) before it shows up. I'm thinking there
>>>>> is a
>>>>> major memory leak somewhere - MS Streets & Trips is my first suspect -
>>>>> but I
>>>>> don't know how to go about getting proof.
>>>>>
>>>>> "David Candy" <.> wrote in message
>>>>> news:%23uUzzbx%23FHA.1600@xxxxxxxxxxxxxxxxxxxxxxx
>>>>> I thought of things all day, researched this and that, but nothing
>>>>> seems
>>>>> likely.
>>>>>
>>>>> I'd try clean boot troubleshooting - type it in Help while online.
>>>>>
>>>>> --
>>>>> --------------------------------------------------------------------------------------------------
>>>>> Goodbye Web Diary
>>>>> http://margokingston.typepad.com/harry_version_2/2005/12/thank_you_and_g.html#comments
>>>>> =================================================
>>>>> "Wowbagger" <none> wrote in message
>>>>> news:%23oR2Cop%23FHA.2264@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>> At the very bottom:
>>>>>>
>>>>>>>>> Software run on the system:
>>>>>>>>> MS Office 2003
>>>>>>>>> Norton AntiVirus 2005
>>>>>>>>> Firefox
>>>>>>>>> MSIE
>>>>>>>>> GAIM
>>>>>>>>> MS Streets & Trips 2005
>>>>>>>>> Google Desktop Search
>>>>>>>>> MS AntiSpyware
>>>>>>>>> GoToMyPC
>>>>>>>>> MusicMatch Jukebox (suspected this one first, but couldn't
>>>>>>>>> demonstrate
>>>>>>>>> a
>>>>>>>>> link)
>>>>>>
>>>>>> "David Candy" <.> wrote in message
>>>>>> news:OBzL%23Dp%23FHA.2812@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>> application list is at the bottom of this post ??????????????????
>>>>>>
>>>>>> --
>>>>>> --------------------------------------------------------------------------------------------------
>>>>>> Read David defending the concept of violence.
>>>>>> http://margokingston.typepad.com/harry_version_2/2005/10/entering_the_ga.html#more
>>>>>> =================================================
>>>>>> "Wowbagger" <none> wrote in message
>>>>>> news:e9tAiBp%23FHA.2036@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>>> Nothing seems to be asking for the full 2Gb. Perfmon usually shows
>>>>>>> handles
>>>>>>> in the 16,000 - 18,000 range if the system is bogging down or not.
>>>>>>> The
>>>>>>> application list is at the bottom of this post - the only other
>>>>>>> thing I
>>>>>>> ever
>>>>>>> use is paint.net
>>>>>>>
>>>>>>>
>>>>>>> "David Candy" <.> wrote in message
>>>>>>> news:edgRUro%23FHA.3064@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>>> Swap files don't care about fragmentation. It is not slower or
>>>>>>> faster as
>>>>>>> they are accesssed by disk location not as a file and nor are they
>>>>>>> sequential. However the more fragments the more memory used to track
>>>>>>> the
>>>>>>> fragments. We've only seen one person here who had a problem with
>>>>>>> this
>>>>>>> (tens
>>>>>>> of thousands of fragments), 2, 3, 50, 100 fragments is irrelevent.
>>>>>>>
>>>>>>> All your symptoms are of a computer with no more memory to allocate.
>>>>>>> Make
>>>>>>> the swap 2 gig (don't defrag - not worth it) and see if that helps.
>>>>>>>
>>>>>>> See other resources, like registry (size or handles), what programs
>>>>>>> do
>>>>>>> you
>>>>>>> run, is one asking for it's full 2 gigs of address space?
>>>>>>> --
>>>>>>> --------------------------------------------------------------------------------------------------
>>>>>>> Read David defending the concept of violence.
>>>>>>> http://margokingston.typepad.com/harry_version_2/2005/10/entering_the_ga.html#more
>>>>>>> =================================================
>>>>>>> "Wowbagger" <none> wrote in message
>>>>>>> news:OrVf5Zo%23FHA.4012@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>>>> Yes - a static swap of 1 Gb located on C: (the only HDD in the
>>>>>>>> system).
>>>>>>>> No
>>>>>>>> fragments - the swap was deleted, the system defragged twice then
>>>>>>>> the
>>>>>>>> swap
>>>>>>>> recreated into a single chunk. The behavior was identical both
>>>>>>>> before
>>>>>>>> and
>>>>>>>> after this operation several months ago. A dynamic swap file was
>>>>>>>> originally
>>>>>>>> used but my heavy disk usage quickly fragmented it to shreds.
>>>>>>>>
>>>>>>>> "David Candy" <.> wrote in message
>>>>>>>> news:OKsiZen%23FHA.356@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>>>> Do you have a swap file?
>>>>>>>>
>>>>>>>> --
>>>>>>>> --------------------------------------------------------------------------------------------------
>>>>>>>> Read David defending the concept of violence.
>>>>>>>> http://margokingston.typepad.com/harry_version_2/2005/10/entering_the_ga.html#more
>>>>>>>> =================================================
>>>>>>>> "Wowbagger" <none> wrote in message
>>>>>>>> news:OxkDCan%23FHA.1988@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>>>>> XP SP2 on a P-4 at 2.4 GHz and 1Gb of RAM.
>>>>>>>>>
>>>>>>>>> The system is usually quite zippy but after several hours of use
>>>>>>>>> the
>>>>>>>>> system
>>>>>>>>> will slow down and act as if it is running out of memory - new
>>>>>>>>> windows
>>>>>>>>> won't
>>>>>>>>> open unless I close existing windows, can't copy/paste to or from
>>>>>>>>> the
>>>>>>>>> clipboard unless I close more applications and the like.
>>>>>>>>> Performance
>>>>>>>>> monitor shows low CPU usage - around 5-20% depending on exactly
>>>>>>>>> what I
>>>>>>>>> am
>>>>>>>>> doing and available physical memory usually shows 256-512Mb and
>>>>>>>>> the
>>>>>>>>> commit
>>>>>>>>> charge typically running about 1/2 of the limit (peak is usually
>>>>>>>>> less
>>>>>>>>> than
>>>>>>>>> 1/2 of the limit as well). A simple reboot and all is well once
>>>>>>>>> again
>>>>>>>>> for
>>>>>>>>> another several hours.
>>>>>>>>>
>>>>>>>>> There is no pattern to the "running out of resources" behavior.
>>>>>>>>> Despite
>>>>>>>>> frequent scans for virus, worm or trojan activity nothing has ever
>>>>>>>>> been
>>>>>>>>> found. Norton Antivirus, MS AntiSpyware, Spybot, Hijack This!,
>>>>>>>>> TrendMicro,
>>>>>>>>> Panda and a few others have all been used and came up with exactly
>>>>>>>>> nothing.
>>>>>>>>> I've tracked CPU usage, disk i/o, memory usage, swap activity,
>>>>>>>>> network
>>>>>>>>> i/o
>>>>>>>>> and nothing indicates what is eating up the resources.
>>>>>>>>>
>>>>>>>>> Could somebody please throw a few ideas my way? I've run out of
>>>>>>>>> ideas
>>>>>>>>> on
>>>>>>>>> where to look for the problem. What performance monitors should I
>>>>>>>>> try
>>>>>>>>> watching? I can't even tell where the bottlenecks are.
>>>>>>>>>
>>>>>>>>> Software run on the system:
>>>>>>>>> MS Office 2003
>>>>>>>>> Norton AntiVirus 2005
>>>>>>>>> Firefox
>>>>>>>>> MSIE
>>>>>>>>> GAIM
>>>>>>>>> MS Streets & Trips 2005
>>>>>>>>> Google Desktop Search
>>>>>>>>> MS AntiSpyware
>>>>>>>>> GoToMyPC
>>>>>>>>> MusicMatch Jukebox (suspected this one first, but couldn't
>>>>>>>>> demonstrate
>>>>>>>>> a
>>>>>>>>> link)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


.

Loading