NT 4.0 Roaming Profile Printer Bug Fix
Are you experiencing problems printing on Windows NT workstations with shared printers? If so, here’s a potential source of the problem for users with roaming profiles. When a user logs on to workstation A and connects to a shared printer on workstation B, NT 4.0 saves the user’s roaming profile with the shared printer connection. If the same user then logs on to workstation B, the Print dialog box might not display the locally installed printer. According to Microsoft article Q269623, a buffer sizing bug that affects print spoolers on NT workstations with shared local printers prevents the spooler from properly enumerating all the installed printers. To eliminate this problem, call Microsoft Support and ask for the new version of win32spl.dll released July 26.
NT 4.0 DHCP Bug Fix
When you restart the DHCP Server service, tcpsvcs.exe might hang and display a Dr. Watson error message. A heap corruption problem with the DHCP service can cause the problem when you stop and then immediately restart the DHCP Server service. Microsoft has corrected the problem in an updated version of dhcpssvc.dll released June 2. See Microsoft article Q264492 for details.
New Win2K Memory Leak Diagnostics
Microsoft recently added a cool set of utilities to its download site that help you diagnose memory leaks. You can download the five User Mode Dump Heap (UMDH) utilities listed below from http://download.microsoft.com/download/win2000platform/utility/1/NT5/EN-US/umdhtools.exe
- gflags.exe sets the appropriate Registry entries for the application that you want to analyze. The OS looks at the Registry entries to determine whether to track an application's heap allocations.
- tlist.exe lists all the processes running on a machine and their related process IDs.
- umdh.exe dumps the heap allocation information for a specific process by process ID. The information includes the callstack for each allocation, the number of allocations made through that callstack, and the number of bytes consumed through that callstack.
- dhcmp.exe compares two UMDH log files to determine whether and where a possible memory leak is occurring.
- dhcmpgui.zip also compares two UMDH log files, but it includes a GUI. The .zip file contains the file dhcmpgui.exe and its C++ source code. The GUI version calls dhcmp.exe, so make sure you install that file in the directory from which you run dhcmpgui.zip.
Before you collect memory use statistics, you must also install the correct debug symbols for your application's components and for Win2K. By convention, you install OS symbols in the Symbols directory of the system root. UMDH locates the symbol files by resolving the environment variable _NT_SYMBOL_PATH; you define the location of the symbol files by typing the command
set NT_SYMBOL_PATH=%windir%\symbols
Microsoft article Q268343 includes a reasonably good description of the procedure you must follow to analyze heap usage. First, you run gflags.exe to instruct the kernel to track heap usage and stack calls. Gflags can collect heap information systemwide or for a specific process. To enable systemwide data collection, type the command
gflags –r
To enable data collection for a specific program, type the command
gflags –I
Unless you have a very sophisticated problem, you probably want to enable memory usage tracking for one process only. If you enable systemwide heap tracking, I suspect that even a very fast system will slow to a snail’s pace, and you’ll end up with much more data than you need to perform your analysis.
Second, to make sense of the log file data, you need to load the debug symbols for the process you're analyzing. Without debug symbols, you can't correlate a memory address with a specific function. After you load the debug symbols, start the process you want to analyze and run tlist.exe to display its process ID. At this point, you have enabled heap/stack tracing, you have symbol files that turn memory addresses into function names, you have a process to analyze, and you have its process ID.
Third, to activate data collection, start umdh.exe with the process ID as a command-line argument. If you want to collect data for a process with a process ID of 97, type the command
umdh.exe –p:97
to display heap usage information directly on the screen in the console window. To save data in a log file called umdh1.log, pipe the output to a file with the command
umdh.exe –p:97> umdh1.log
To ensure you that don’t overwrite the initial data with data from subsequent runs, enter a unique log file name each time you invoke umdh.exe.
Let the process run until you get beyond the point at which you think the memory leak is occurring. If one log file doesn't contain enough information for you to identify the leak, you might need to repeat the procedure and collect another round of data. When you have a couple of log files of memory usage data, you can compare the log files with either dhcmp.exe or dhcmpgui.exe.
