Charles Carroll recently used our Technical Q&A to find the modern equivalent of a DOS recorder program he once used.

“Some years ago Tom Kihlken wrote a DOS app called Recorder, which would list and count files touched—created, read, [and] written. His purpose was to support RAM disk speed performance by putting most frequently used files in RAM disk. I am looking for a tool that does this to speed troubleshooting when an app runs fine on one workstation and not another,” Carroll wrote, “I haven’t been able to find a Windows NT 4.0 version of this tool.”

Within a day, he had several acceptable responses. Here’s what he found out.

In-house app causes run-time error
The problem application was an in-house developed VB6-Oracle8i program that connects client machines to an Oracle 8.1.7 database. Carroll had two identical client machines built using the same disk image. One was able to access the database without problems; the other displayed the following error, Run-Time Error 3706—Provider Cannot Be Found. It May Not Be Properly Installed.

(Read this sidebar for more information about Carroll’s specific database issue.)

Carroll hoped to find a “recorder” program for NT 4.0, similar to Kihlken’s DOS application. He could then observe the files each machine touched when starting the problem application and look for differences between the two machines.

Two possible solutions emerge
The first answer came from member Florinel who suggested Carroll try Apimon.exe from the Windows 2000 resource kit. The Help file from the Apimon program states that it can generate two types of reports:

  • ·        A report containing all API calls showing their counts and times
  • ·        A report showing a trace of all APIs as they occur in time

Even though Carroll was looking for an NT application, he thought Florinel’s suggestion might work anyway, as Windows 2000 has an NT core.

Before Carroll could try Florinel’s suggestion however, TimTheToolMan recommended these utilities from the Sysinternals Web site:

  • ·        Handle v2.01, which shows what files are open for which process
  • ·        ListDLLs v2.23, which lists all loaded DLLs and their version number
  • ·        Process Explorer v5.23, which lists the files, registry keys, and other objects that a process has open and who owns that process

Of these three programs, Carroll believed Process Explorer would best help him solve his current problem. But Carroll also thought this handy application would be helpful in another way.

Process Explorer would allow him to compile a list of the DLLs used by the core programs on the disk images of his organization’s workstations. With this first list in hand; he could then develop a second, nonredundant, supplemental list of DLLs used by the disk image’s noncore applications. What would he do with these lists?

Carroll’s organization, which has offices around the globe, outsources its help-desk functions to several international companies. As part of any software or hardware implementation, his organization submits help-desk scripts to these outside firms. With this documentation, Carroll would also include his lists of core and supplemental DLLs to aid with troubleshooting. “It makes sense to do a Process Explorer type check as part of implementation and configuration management,” he said.

Resurrect an application from the past
Like Carroll, you might be able to find a new adaptation of a program that’s now long out of date. Members suggested two potential programs to replace the DOS program he remembers as being so helpful in the past.

“I am sure Process Explorer would have done the trick,” Carroll said, “Although it would be a bit cumbersome.”

If you are looking for an equivalent program to one that doesn’t work for you now, post your question in our Technical Q&A.