>>>The code for the program is scattered across different methods. I can supply it if it is helpful. Here is basically what I do:
>>>
>>>1) Use FCREATE() to create an input file, and close it with FCLOSE().
>>>2) Call Win32 CreateFile() to create a log file.
>>>3) Call Win32 CreateProcess() to call c42pdf.exe. Redirect standard error and output to the log file (step 2). Hide the DOS window by changing ShowWindow field in StartupInfo.
>>>4) Get process and thread IDs from ProcessInfo.
>>>5) Call Win32 WaitForSingleObject() to wait until process is complete.
>>>6) Call Win32 TerminateProcess() to end process.
>>>7) Call Win32 CloseHandle() to close thread, process, and log file (step 2).
>>>8) Use FOPEN() to open log file, FGETS() to read it, and FCLOSE() to close it.
>>>
>>>Do these steps sound reasonable? Are these some additional steps that might help?
>>>
>>>Thanks!
>>
>>Tim,
>>
>>Sorry, I mis-read your post (didn't see the DOS business). It looks right, but it sounds like there's a memory leak somewhere that's eating up resources. That would explain the diminishing speed.
>>
>>I don't think that the WSH can help here unless a script file running under the console was used.
>
>I have not looked at WSH. I might check it out. Maybe the memory leak is with the c42pdf.exe. Is there a way to monitor this with Performance Monitor? What would I look for?
>
>Thanks!

I think David pointed you in the right direction here. I see DOS and I start thinking cscript.exe (which runs in the console). It's hard to say what you should look for other than a significant drop in any one of the three resources monitored. If I were to hazard a SWAG, I'd be inclined to think System rather than User or GDI, but if any or all of these start dropping without being recovered after termination, you may have found the culprit.

BTW, the application, c42pdf.exe, does close its DOS window, doesn't it?