What happened under the hood while you've been waiting for Windows desktop to appear.

Altough Windows 95 (and Windows for Workgroups 3.11 for that matter) has provided an organized way to load VxDs dynamically, still the overall behaviour of any particular installation is largely defined by its statically initialized part which executes far before Windows desktop appears on the screen. This is because most of resources allocated or initialized by the Virtual Machine Manager (VMM) and VxDs will be in effect as long as Windows is running. Often times, the need arises to get a peek at those resources. For example, numerous times I've heard a question 'how do I know which IRQs and hardware ports are virtualized on my system?'. COREDUMP provides answers to many such questions.

COREDUMP is a Win32 console application. As such, it will not work in Windows 3.x, not even with Win32s installed, but if you do need that, send me a message. There is a 16-bit version of the program, but I just didn't bother to recompile it for years - nobody seems to be interested in 16-bit Windows anymore! If you have seen my REGSPY95 utility, you'll immediately recognize the user interface. This is not accidental, in fact, REGSPY95 was modelled after COREDUMP, and it also uses the same VxD called FOOTPRNT. This driver traps VMM and VxDs accesses to a number of system calls made at initialization time, that is, from the beginning of Sys_Critical_Init to the end of Init_Complete messages inclusive, and collects the calls information in its internal buffers. Other than those buffers, FOOTPRNT itself doesn't leave to much footprint behind as the driver discards most of its code when it detects that last VxD in the device chain has finished processing Init_Complete message. COREDUMP then can be run at any time showing you precisely what was happening You have 2 options to organize COREDUMP's output: by grouping accesses to identical resources, or by showing accesses in chronological order. Here is the excerpt from the output that answers the above question as it pertains to my machine:

===== VPICD_Virtualize_IRQ =====
 Caller   IRQ  Options HwInt Proc Virt Int Proc EOI Proc Mask Proc IRET Proc
--------  ---  ------- ---------- ------------- -------- --------- ---------

VPICD     2       1     C009AA3E           0     C0099CD4 C009A806  C009AA3E
VTD       0       4     C009C890    C009C907     C009C944        0  C009C94A
VKD       1       0     C00D0C7C    C00D0628     C00D05F8        0  C00D0644
IOS       A       4     C1024BF0           0     C1024B74 C1024B5C         0
VMOUSE    C       6     C00D29C0           0            0 C02BC9C5         0
VMCPD     D       0     C00A4325    C00A43A1     C00A43A8        0         0
NDIS      5       4     C00B464F           0            0        0         0
IOS       6       2     C633D1EC           0     C633D349        0         0
IOS       B      26     C633F355           0            0        0         0
IOS       E       6     C6344DC4           0     C6344EEC        0         0
PharLap   D       2     C00CD2E0           0            0        0         0
VCOMM     4       6     C6366238           0            0        0         0
VCOMM     3       6     C6366238           0            0        0         0

Even if you aren't familiar with Virtual Programmable Interrupt Controller (VPICD) and its VPICD_Virtualize_IRQ service, this output should make a lot of sense to you. For example, the first line shows that VPICD itself has virtualized IRQ 2 on my system (and on yours too). This is because on PCs, the secondary slave interrupt controller (Real, not Virtual!) is connected to IRQ2 line of the primary master PIC. The timer chip is on IRQ0 hence VTD (Virtual Timer Device) has to virtualize it, keyboard is on IRQ 1 and this is handled by VKD, and so on. The output also gives you linear addresses of different functions that VxDs submit to VPICD_Virtualize_IRQ in order to be notified of various events relavant to a corresponding hardware interrupt such as when the physical EOI command was issued. You can use this information to set a debugger breakpoint on one of those addresses, for example, or to disassemble at them (and the not-so-free version of COREDUMP will do it for you automatically!).

There is a lot of useful details shown here, and COREDUMP will show you a lot more. The list of services FOOTPRNT currently traps (excluding those provided for REGSPY95), includes the following:

In other words, COREDUMP is an excellent starintg-point tool for exploring Windows 95 internals. Besides, it also works in beta 2 version of Memphis, aka Windows 98. There is a number of options you can use to control FOOTPRNT/COREDUMP behaviour, or for troubleshooting in case something goes wrong. See readme.txt file accompanying the distribution package. But don't forget, in order to run COREDUMP (or rather to get information from it), you need to install FOOTPRNT.386 on your system. As the static VxD, you install it either through SYSTEM,INI or through the Windows Registry. Also, when you run COREDUMP, you have an option to supply it with the text file(s) containig VMM/VxDs names and names of their services. This will make some parts of COREDUMP's output more meaningful. The easiest way to generate such file(s) is to use a set of AWK programs found here. Depending on how you configure it, the amount of information COREDUMP provides, will vary but almost certainly, it will not even nearly fit on your screen. Therefore, it's recommended to redirect the output to a text file.


Download COREDUMP.ZIP

This page has been visited times since Mar-24-1998

Last updated: November 10, 1997.
Copyright @ 1997 Alex Shmidt. All rights reserved. 1