Troubleshooting an MS-DOS application which hangs the NTVDM subsystem in Windows XP and Windows Server 2003

I’ve been working on an intriguing (and frustrating) issue for a few weeks now and a couple of days back we finally resolved the issue.

My client has an MS-DOS (FoxPro 2.6a database) application running within an NTVDM on Windows XP. Every now and then, the application will hang – seemingly randomly. Windows XP did have service pack 2 applied, but the issue also occurs on service pack 1 PCs (I didn’t try the RTM version). Only the application hangs – it is possible to terminate the NTVDM process and carry on working as normally.

Normal actions for troubleshooting MS-DOS applications in Windows XP were not helping to resolve the issue, but the software vendor managed to narrow the issue down to FoxPro waiting for input. Occasionally, the input does not timeout and return control to the calling program – it seems that this is the root cause of the NTVDM hang. Identifying this allowed them to construct a test program which polled for input, timing out every few seconds and would reliably hang an NTVDM at a seemingly random time, but always within an hour.

Using their test program on a variety of PCs, the software vendor found that the problem was related to the Intel hyper-threading technology (my client has standardised on a version of the IBM ThinkCentre M50 which includes a single 3GHz Intel Pentium 4 processor with HT technology). Whilst disabling hyper-threading is unlikely to result in any significant performance degradation (hyper-threading only provides an average 10-20% performance gain as most applications do not fit completely with the hyper-threading model), it was still considered by IBM, Microsoft, my client and myself as a tactical workaround, rather than a strategic fix.

After seeking advice from Microsoft, I ran the test program on a Compaq ProLiant DL380 G2 server with two Pentium III 1.26GHz processors and found that the issue is not limited to Windows XP and hyper-threading, but to both Windows XP and Windows Server 2003 when running with an ACPI Multiprocessor PC HAL. Turning off hyper-threading on the PCs was no longer good enough as we can expect to see multiple processor cores constructed on a single die in the near future, leading to a rise in the use of multi-threaded applications (the logical processor provided by the hyper-threading technology in the Intel Pentium 4 processor is simply a precursor to this).

So why does an MS-DOS application running within an NTVDM on a 32-bit version of Windows use multiple processors? The answer it seems is that although the MS-DOS application is not multi-threaded, modern versions of Windows are, and can allocate parts of the NTVDM process to any available processor. With that in mind we re-ran the test program with processor affinity set to use only CPU0 in Task Manager. The results were the same as disabling hyper-threading – no NTVDM hang! Obviously, setting processor affinity manually is not sustainable outside the test environment, and short of running the application on Windows Server 2003 Enterprise Edition (with the Windows System Resource Monitor to control processor affinity) we needed to find an alternative solution.

That solution came in the form of the imagecfg.exe tool provided with the Microsoft Windows 2000 Resource Kit (supplement one). This can be used to edit an executable file and permanently set the processor affinity for a given application:

Using the imagecfg -a 0x1 c:\windows\system32\ntvdm.exe command did the trick, although Windows File Protection/System File Checker quickly restored the original ntvdm.exe file so I needed to perform this on a copy of ntvdm.exe in a temporary folder, and then overwrite both c:\windows\system32\ntvdm.exe and c:\windows\system32\dllcache\ntvdm.exe.

Once updated, the NTVDM process runs on CPU0. Of course, this limits all programs under the control of the NTVDM subsystem but it is far more preferable to disabling logical or physical processors in the BIOS; however, as this is a change to an operating system file, it must be considered alongside the implementation of any service packs and/or hotfixes from now on. Reversing the change is simply a case of restoring the original ntvdm.exe file.

95 Comments

  • Saturday 19 February 2005 - 15:12 | Permalink


    hi, just wanted to ask whether there is any other known cause of ntvdm.exe cpu overload – even when running on virtual CPU 0 or modified with imagecfg tool. is there any possibility of directx 9 and ntvdm inter-un-operability? thanks a bunch for any clue.

  • Thursday 24 March 2005 - 13:56 | Permalink


    It’s funny how these things come around… my client is still trying to get a full resolution to this from Microsoft (who up to now have not been prepared to support the change to the NTVDM.EXE binary). Then, today, I learnt that one of the Microsoft Windows Escalation Engineers has actually sent my client a link to this post as an example of a possible resolution!

  • Blazej Kotelko
    Tuesday 6 December 2005 - 13:00 | Permalink


    We experienced the same problems with our FoxPro/DOS based applications and wrote small a program which starts a DOS *.bat file in one-processor only mode. This does the trick! Usage for our tiny utility is:

    StartHT.exe [-processor number from 0 to 9 (default 0)] name.bat

    For instance:
    StartHT.exe subiekt.bat

    And it works!
    blazej@insert.com.pl
    our software: http://www.insert.com.pl/en/products.html

  • Saturday 21 January 2006 - 16:18 | Permalink


    Gabriel Hakvoort dropped me an e-mail a few weeks back with this extra information:

    “I found something out which we’re testing at the moment. Imagecfg.exe appeared buggy on our W2k3 terminal server. So I copied the ntvdm.exe from this server to my XP desktop and ran imagecfg -a 0x1 on it. Then back to the terminal server. Now it seems to work just fine.

    Maybe this can help other people too?”

    Thanks Gabriel.

  • Anonymous
    Tuesday 21 February 2006 - 2:12 | Permalink


    My 16-bit app (lotus 123R5)crashes (ntdvm loads again, CPU >100%) on any print function. This app has run for years without problems. I suspect installing a new program (Business Vison32) has changed my registry to cause this but I can’t restore. Does anyone have any ideas?.. I’m desparate.

  • Tuesday 21 February 2006 - 11:01 | Permalink


    Re: the anonymous comment with the Lotus 123 issue, Have you recently installed some Windows updates that might have affected NTVDM.EXE? If the problem’s only just started happening, that would be one the likely cause although I guess it could be a conflict with another application.

    It might also be worth modifying the shortcut used to Launch Lotus 123 to run in compatibility mode for an early operating system version.

    Hope this helps, Mark

  • Bernard
    Tuesday 21 February 2006 - 14:15 | Permalink


    Thanks Mark. (Re: anonymous)I’m not aware of a Windows update and I have tried earlier compatibiltiy modes.This problem doesn’t manifest on other xps. There seems to be a unique setting in my XP that now causes Lotus print functions (and, only print) to try to load Lotus a second time.

  • bernard
    Tuesday 21 February 2006 - 20:41 | Permalink


    I think my problems may have disappeared. I made a number of changes. Unfortunately, I didn’t test after each change. However this observation might help. A few weeks ago, on adding a wireless router to my office’s small wired network, the system created a large list of everyones’ shared printers (maybe 40 printers)in my control panel. Today, I deleted all these printers except a few local and a few network printers…and now Lotus is not crashing (for now). Is it possible that this large list was causing the crash? Thanks for your earlier comments and this blog… a great comfort in this great unsupport wasteland.

  • Wednesday 22 February 2006 - 6:55 | Permalink


    Hi Bernard,
    I’m glad my comments were of some help, even if they didn’t actually provide the answer to your problem.

    40 print queues does sound a lot for a DOS application to handle (I doubt it was designed for that many) but fortunately my days of supporting DOS applications on Windows seem to be over (well, I thought they were until I came across the issue that let to the original blog post)!

    Thanks for the feedback.

    Mark

  • Erik V. Olson
    Thursday 16 March 2006 - 19:34 | Permalink


    Just wanted to say thanks. Had a very similar problem with a dual-core processor PowerEdge 850, and manually setting the CPU affinity to one processor fixed it.

  • Anonymous
    Wednesday 7 June 2006 - 15:26 | Permalink


    it’s seem that this tool doesn’t work with dual-core cpu.

    I’ve try it on a dell optiplex gx620 with a pentium D820 inside but my apps seem to always use the two cpu and hangs randomly.

    Another idea ?

    Thanks, Mathieu.

  • Wednesday 7 June 2006 - 15:51 | Permalink


    Hi Mathieu,
    Not sure why your dual-core CPU is not working but Eric v. Olson’s is. Are you sure that the original (unmodified) .EXE is not getting copied back?

    Alternatively you could try Blaze’s utility.

    Mark

  • WoZ
    Thursday 15 June 2006 - 23:47 | Permalink


    Hi, my english is not so good… so excuseme. I have an windows 2003 server with 50 terminal services users, they run a foxpro 2.6 app but is for windows (foxpro 2.6 for windows

  • WoZ
    Thursday 15 June 2006 - 23:53 | Permalink


    I have a terminal server (windows 2003) with 50 clients running ERP software developed on foxpro 2.6 for windows. That software run over ntvdm.exe and hang randomly… why? I don’t now. When ntvdm hang the cpu usage is 100% and the server is very slow, the “solution” is end the ntvdm process for the hung user and the server wake up again. My server was an Athlon 64 2800+ 2 GB ram 450 GB hd. I think that an application of 1994 should run very well on that system, but is not possible yet.
    I hope that you can help me with my big problem. Greetings byebye

  • Tuesday 4 July 2006 - 0:23 | Permalink


    Woz, Your problem is pretty much exactly the issue that I experienced. If you read the comments on this page there are various solutions suggested for setting the processor affinity. Alternatively, the August 2006 issue of Personal Computer World magazine suggests using the Active+ RunFirst utility to set processor affinity.

    Basically FoxPro, NTVDM and multiple CPUs don’t play nicely together.

    Mark

  • Anonymous
    Friday 4 August 2006 - 2:59 | Permalink


    Does anyone know where I can find Startht.exe?

  • Anonymous
    Sunday 24 September 2006 - 16:53 | Permalink


    FOR CLARIFICATION:

    This problem does NOT occur on Windows 2000 (HT, Dual CPU, or Dual Core, etc). Only XP and 2003 are affected!

    HOW TO REPRODUCE THE PROBLEM QUICKLY:

    Launch Foxpro:

    FOXPROX.EXE [ENTER]

    Now move the Command Window around in a circle with the mouse. In under 30 seconds:

    HANG! (usually takes under 10 seconds on my X2 4400+)

    Try the same thing under Windows 2000:

    No problems! (I just tried this on a dual cpu Xeon system with hyperthreading enabled, W2K server, and a W2K P4 HT system).

    XP Blows.

  • Jeff
    Wednesday 27 September 2006 - 20:08 | Permalink


    Hi, I tried Active+ runfirst utility, but it does not appear to help with Foxpro. ntvdm still runs on both CPUs.

    I am trying to use imagecfg with Terminal Server 2003, but Windows keeps on resetting the file even though I modified system32 & dllcache. I even put an entry in i386. Any ideas?

  • Wednesday 27 September 2006 - 23:28 | Permalink


    Jeff, when I originally had the problem, Windows File Protection/System File Checker quickly restored the original NTVDM.EXE file. It sounds as though that’s what’s happening to you too. It’s a long while back but from reading the blog post it looks as if my workaround was to make the changes on a copy of NTVDM.EXE in a temporary folder, and then overwrite both c:\windows\system32\NTVDM.EXE and c:\windows\system32\dllcache\NTVDM.EXE. Beware though that this would not be supported by Microsoft (even though it was suggested by one of their consultants!)

    HTH, Mark

  • Anonymous
    Friday 20 October 2006 - 11:08 | Permalink


    Thanks for the assistance with this problem. I’ve been driven mad by this for days.

    Our issues were resolved by running Foxpro with the -X switch instead of the +X which loads an extended version into memory, .25Gb of it in our instance.
    Also, utilising NTVDM version 5.1.2600.1106 resolved all issues without changing +X or affinity.
    I think this version is from SP1 but don’t quote me.

    Thanks,

    Martin Hobson – NHS IT Manchester

  • Anonymous
    Tuesday 21 November 2006 - 14:46 | Permalink


    Does anyone know if copying the NTVDM.EXE file from a Windows2000 machine to an XP machine will help?

  • Vikas Aggarwal (midtowngrand@gmail.com)
    Thursday 23 November 2006 - 9:09 | Permalink


    Thanks a lot for solving this one of my long pending headache.
    I have not been able to solve it since i got myself a new pc with Intel 945 Motherboard. Most of my applications are in Foxpro 2.6 for Dos and I had to run them on Windows 98.
    At last I could fix the problem by reading your beautifully explained issue.
    Hats off to u.. Mark !!
    Vikas

  • Thursday 23 November 2006 - 22:35 | Permalink


    To the anonymous commenter above, I’d be surprised if using the Windows 2000 NTVDM.EXE with Windows XP didn’t cause you some problems somewhere. At the very least it would be unsupported – you might as well use the patched version of the Windows XP one.

  • Thursday 8 February 2007 - 20:54 | Permalink


    Even after copying ntvdm.exe to a temp folder, making the change there, and replacing the files in System32 and DLLCache, I still see in Event Viewer that Windows File protection has overwritten the files, and no change to my CPU Usage stats – immediately to 100% after launching the ntvdm process.

    Is there a certain way I should perform this in a temp folder and do the overwrite other than copy/paste?

    Thanks so much for this post.

    Windows Server 2003

  • EDDIE
    Tuesday 13 March 2007 - 20:16 | Permalink


    Hey JHC!

    You need to shut down th Systems Restore Capability, reboot the machine, apply the affinity w/imagecfg. Delete the other copy in DLLCache and then put back the System Restore. This will do it.

  • Mark C
    Wednesday 11 April 2007 - 1:31 | Permalink


    This was a great article – But. I tried to implement this kludge on Windows Vista.

    1) FP2.6 DOS was crashing, corrupting data (yay!)
    2) Windows Resource Protection quite successfully prevented me from changing ntvdm.exe

    The simple fix: I found the START command in Vista and W2k3 server (Not sure about XP):

    — display —

    C:\Documents and Settings\Administrator>start /?
    Starts a separate window to run a specified program or command.

    START [“title”] [/D path] [/I] [/MIN] [/MAX] [/SEPARATE | /SHARED]
    [/LOW | /NORMAL | /HIGH | /REALTIME | /ABOVENORMAL | /BELOWNORMAL]
    [/AFFINITY ] [/WAIT] [/B] [command/program]
    [parameters]

    (more explanation…)
    — end display —

    … so my batch file looks something like:

    start “my title” /D “C:/MyFoxApp” /AFFINITY 0x1 C:/FP/FOXPROX.EXE “C:/MyFoxApp/app.exe”

  • Wednesday 11 April 2007 - 7:20 | Permalink


    Mark C – thanks for this – nice workaround (start is there in XP too).

  • fmcgowan
    Friday 1 June 2007 - 19:09 | Permalink


    I am having similar problems with FPD apps that ran correctly for years on W2k. Now on XP, they are apparently updating the CDX but not the DBF on data updates.

    Though “Start” does exist on XP, the “affinity” keyword is not supported… too bad, it could have made life much simpler.

  • Anonymous
    Sunday 3 June 2007 - 3:12 | Permalink


    Update:

    Using any version of ntvdm.exe from XP or 2003 does NOT work. The only solution is set the processor affinity to one cpu or: upgrade to Windows 2000.

    If you are using a telnet server such as Georgia Softworks to run FPD apps. Then you have no choice: Windows 2000 Server. Locking the affinity down to one CPU practically defeats the purpose of a telnet server.

    Facts:

    – This affects Foxpro for DOS Extended 32 Bit (FOX +x, FOXPROX)

    – It does not affect regular FPD 16 bit apps (your apps might run with the -x switch, but they will run slower, or may not run at all; if your FPD apps were developed to run using the 32 bit extender like mine have, and no 16 bit testing, I guarantee you will have problems)

    – This problem has persisted for over 5 years, Microsoft obviously doesn’t care and won’t fix it!

    – For multiuser apps, lots of folks are using DOSEMU running under Linux

    To reproduce the problem:

    Launch Foxpro extended 32 bit: FOXPROX.EXE [ENTER]

    Move the Command Window around in a circle with the mouse. In under 30 seconds the app will hang causing 100% cpu utilization on one processor.

  • Norman Eastwood
    Tuesday 26 June 2007 - 22:48 | Permalink


    ok, I have tried to follow this thread, but must be too slow. I too have an old fox pro DB that runs well on Win 2000 sp4, but hangs, crashes, or i/o errors out in three other XP machines. I don’t know if the processors are dual processors, but they are older machines so I don’t think so. 1), What would be the work around for a non-dual processor machine and 2), asuming I want to try the March 13 solution of making changes to the NTVDM file and copying back into the OS, what changes do I need to make to the file, and how do I disable windows defenses so I can copy ( and it will stay ) back into the os? thanks

  • Sunday 1 July 2007 - 19:36 | Permalink


    Hi Norman,
    1. The problem doesn’t just occur on dual-processor machines – it’s on machines with hyperthreading too – bearing in mind I wrote this two and a half years back that covers a lot of machines.

    2. The changes are, as in the original post, running the imagecfg -a 0x1 c:\windows\system32\ntvdm.exe command (imagecfg.exe needs to be downloaded from Microsoft). Then, to make the edited version of ntvdm.exe “stick”, follow Eddie’s advice from 13 March 2007.

    HTH, Mark

  • Monday 16 July 2007 - 18:04 | Permalink


    Mark,

    Mainly wanting to say THANK YOU VERY MUCH for this information. I have some screens I still need to modify with FoxPro for DOS.

    In case this may be useful to others:

    I couldn’t find the imagecfg.exe readily on the link above, but this one has it:

    http://www.robpol86.com/Pages/imagecfg.php

    Also, the c:\Windows\System32\dllcache folder seems very well hidden. Even with View options set to show it, I could not find it via Windows Explorer. So I got to it via the Command prompt.

    Oh yeah, the fastest way I found to test for the problem is similar to what was said above, though slightly different. Open a screen via:

    MODIFY SCREEN ANYNAME

    Then hold the mouse key down and drag its “selection” box back and forth – it freezes for me in seconds without the above fix.

    I am running XP Pro SP2 with an AMD X2 4200+.

    Thanks again for these instructions as they helped me resolve some serious issues.

  • Terry
    Sunday 5 August 2007 - 22:20 | Permalink


    My DOS based Lotus123 worked AOK in Windows 98SE and XP. Now in Windows Vista, trying to load a “large” (only 260K) .WK1 file causes “Memory full” error message. Opening 123 in Compatibility Mode for 98SE or XP fails to resolve this. Suggestions for a fix?

  • Monday 6 August 2007 - 9:32 | Permalink


    Hi Terry,
    You’ve tried what I would normally suggest to get a legacy application working under a modern version of Windows. The only thing I could suggest now (apart from porting the legacy application to a supported platform) is to run one of the operating systems that it will run on (even MS-DOS) in a virtual machine – Microsoft offers Virtual PC 2007 free of charge.

    HTH, Mark

  • Kent
    Friday 17 August 2007 - 18:30 | Permalink


    I tried the imagecfg patch. That worked ok on a temp copy of NTVDM.EXE but I can not get it to stick in the c:\windows\system32 folder. I turned of System Restore in the My Computer / System Restore page and rebooted but it still will not let me copy the patched file in the c:\windows\system32 folder.

    What is the trick to get the patch to stick ?
    Thanks,
    Kent

  • Kent
    Friday 17 August 2007 - 20:01 | Permalink


    I have solved the sticking problem without having to turn off system restore. I updated the c:\i386\ntvdm.exe with the patched version first, then i was able to update the c:\windows\system32\ntvdm.exe and the patch sticks. When I checked my program in the task manager it shows it running on only one cpu.
    Thanks again for your help,
    Kent

  • Naish
    Thursday 18 October 2007 - 12:41 | Permalink


    Mark,

    I’m another one writing to thank you so much for this very valuable info.
    I support a Fox2.6 DOS application on a number of different PC’s, and had been having problems with the application hanging on newer PC’s.
    I tried your suggestion of running imagecfg on the ntvdm.exe, and XP kept putting it back to it’s old state.

    When I followed Kent’s suggestion (17-Aug-07), and moved c:\i386\ntcdm.ex_ away, the modified version of ntvdm persists and all is well. MARVELLOUS !!

    I have also tried to resolve the same problem on Vista, using MarkC’s entry (11-Apr-2007) ie using the start command.

    This works fine from a command prompt, and resolves the hanging problem. Unfortunately, I don’t think the start command is allowed in a PIF file.

    I need to invoke the program through a PIF file, so I can specify my own Config file for the app to increase FILES, and also to configure the Extended Memory.

    I wonder if you have any ideas.

    Once again
    Thank you

  • Friday 19 October 2007 - 10:15 | Permalink


    .PIF files – now we’re going back into the deep recesses of my mind ;-)

    The only thing I can think is to have a chain of files so that the .PIF is used to launch another batch file which then calls the start command. It’s a bit messy but it may work.

  • Lucian
    Friday 11 January 2008 - 8:27 | Permalink


    I have a similar problem trying to run a dbase program in windows 98, which is in a virtual pc on a windows xp machine. The problem appears when i move the mouse or press the keyboard. I found on some sites it could be a problem of input polling/grabbing. This solution of yours does not applies to me, as i don;t have either hyper or multi processors.

  • Friday 11 January 2008 - 9:01 | Permalink


    @Lucian – it’s a long while since I worked with this issue but yes, I think the developers said that it was an input polling/grabbing issue. I’ve not seen the problem occur with single-processor (non-HT) machines but yours could be slightly different as you ware working on Windows 98 (not NT/2000/XP/Vista) and using a different database program. Good luck finding a resolution – I’d normally suggest trying virtualisation to sandbox the application but it seem you are already doing that.

  • Sujit Kumar
    Thursday 17 January 2008 - 10:51 | Permalink


    Hi.
    I have an application which runs properly on the Win 2000. But when I tried to run on XP Dual Processor machine, it simply hangs after 4 transactin. But after changing its affinity to one of the processor application works till 45 transactions and later hangs. Can any body tell me what is the solution for this problem. We are running MFC application on XP and Win 2k.
    Regards,
    Sujit kumar

  • Anonymous
    Tuesday 5 February 2008 - 22:15 | Permalink


    The solution:

    Convert one site, 18 users to Linux/DOS EMU/Samba/Putty – Success.

    Convert one site, 7 users to Linux/DOS EMU/Samba/Putty – Success.

    Convert large multi site, total 61 users Linux/DOS EMU/Samba/Putty – Success.

    Nine sites to go, 144 users.

    All because: Microsoft will not fix the problem.

    This solution is very nice, but not easy to setup. The linux kernel handles these apps surprisingly well. Better than NTLM as it doesn’t have that CPU hogging issue which slows the system down and makes your keystrokes unresponsive (unrelated to the lockup issue). Network file access is also slightly faster.

  • Tuesday 5 February 2008 - 22:34 | Permalink


    @Anonymous. I’m glad you managed to fix the problem by going down the open source route but that’s not the real point here. In my customer scenario, they were running a critical business application on an old and unsupported version of Fox Pro for DOS. IMHO, if it was that critical to them then they really should have replaced it with something more modern. Amazingly, this post is still getting hits 3 years later from people in a similar situation!

    Microsoft gets flak for providing too much legacy support (and hence spaghetti code/bloatware) but when they say no to supporting a 15-year-old application that’s wrong too! There is a workaround (documented in this post) and it’s not that hard to implement (certainly easier than migrating applications to a new platform). Virtualisation is another option but, let’s face it, is a customer with a couple of hundred users who won’t upgrade to modern software really going to bother Microsoft? I doubt it.

  • Manokar
    Monday 11 February 2008 - 0:08 | Permalink


    Hi,

    Pl. try out this, Make a DOS Batch file to run the Foxprox Exe file and make check the Compatibility Mode (Run in ) for Win98SE/Millenium will solve this problem.

  • Monday 11 February 2008 - 0:13 | Permalink


    From recollection, compatibility mode didn’t do anything to assist with this issue.

  • Anant Jain
    Saturday 17 May 2008 - 13:57 | Permalink


    I am using foxpro 2.6a (Dos Based) when system running in any process contineously then it goes to hang,

  • Imtiaz
    Thursday 22 May 2008 - 7:28 | Permalink


    The imagecfg is a good tool to set processor affinity, CAN ANY ONE
    KINDLY HELP ME TO USE INTERNET EXPLORER ALWAYS ON SINGLE CORE or help permanently disable one core in a C2D Processor

  • Monday 16 June 2008 - 13:33 | Permalink


    Here is a simple & elegant solution:
    http://mx.esc.ru/~assur/soft/vaffinity/

    No binary patching, no startup script changes, random CPU selection for multiple ntvdm instances. Sources included.

  • Sharon
    Friday 20 June 2008 - 7:42 | Permalink


    I am working with Foxpro 2.5a X (DOS) under Win98, XP Prof, and with many different CPU’s types. Nowadays my PC is a Quadcore Dell.
    Others are DualCore.

    Even when I experience troubles (from time to time) they’re most focussed in ACTIVATE WINDOW sentences and when TRACING (debugging) the program (just in some PC’s). Recently I’ve experienced more troubles with debugging under QuadCore CPU but it seems that working with FULL SCREEN option reduces considerably the trouble.

    Anyway, we are working with up to 10 PC, all XP Prof. and just some of them, from time to time, get hanged. I would say 1 PC hangs 6 times per year. I start with a .bat with C:\FOXPRO\FOXPROX BEGIN.

    HTH
    Sharon

  • Júlio Nobre
    Monday 4 August 2008 - 16:17 | Permalink


    First of all, I just would like to thank Mark (and anyone who ever helped him) on this hanging problem since this webpage is just priceless.

    Packaged a solution based on IMAGECFG.EXE

  • Júlio Nobre
    Monday 4 August 2008 - 18:26 | Permalink


    First of all I would like to thank Mark for starting this threading and for his priceless investigation on this subject and everyone that contributed to its discussion.

    I have adapted Alex’s (from Russia) work to provide an autoinstallation package, available at http://sisgarbe.dyndns.org/sispub/WebShared/NTVDM/VAffinity.exe

    Thanks you all guys

  • Monday 4 August 2008 - 19:29 | Permalink


    Júlio – thanks for your kind words – it’s great to know that this information is useful to someone as that’s what makes the time and effort I put into this site worthwhile :-)

    Thanks, Mark

  • Rahul Kadu
    Friday 5 December 2008 - 17:51 | Permalink


    I have old DOS business application developed in 1990 and it’s still in use.On latest dual core pc or hyper threading turned on,my dos application hangs up periodically.I had to restart my application again.PLs help

  • Friday 5 December 2008 - 17:58 | Permalink


    @Rahul – have you tried any of the solutions presented in this blog post and the follow-up comments?

  • Pingback: 16-bit programs on Windows Server 2003 | keyongtech

  • Pablo Crofts
    Thursday 19 March 2009 - 6:56 | Permalink


    A big thank you to Mark and all other contributors;+)
    I have several large FPD2.6 apps running on a variety of PC and network configurations, all under XP.
    The freezing phenomenon has been apparently random and not reproducible, though I have 3 general observations:
    1) It seems, on balance, more likely to happen on exiting from a heavy procedure
    2) Some PC’s are more prone to freezing than others, even though they are identically configured and running the same set of Windows apps.
    3) There seem to be periods when the frequency of freeze-ups seems to be high, but with no pattern (that I can discern).

    I have now tried first Runfirst.exe and then StartHT.exe.
    Both seem to do the job – no lockups so far in one week of running on my test machine. Early days yet, but it’s already encouraging…

    Interestingly, setting the affinity to -1 using StartHT produces sharply improved responsiveness compared to -0, so I’ll continue with that.

  • Steven price
    Tuesday 24 March 2009 - 7:35 | Permalink


    Hi

    I have the same problem described above with an old xbase++ application. Do we have to set processor affinity on the win2K server (SBS) or on all the client PCs. It loooks easier to use startht in the batch file we use to start the application rather than alter ntvdm, is thsi correct or have I misunderstood ? We use XP clients mainly with single processors

    Thanks for your help

    Steve

  • Tuesday 24 March 2009 - 10:17 | Permalink


    @Pablo – thanks for posting your findings here – glad you found this thread useful!

    @Steve – I’d expect that the changes need to be made where the application is executing – if that’s on the clients then that’s where the change would be. Even if those clients have single core CPUs they may have hyperthreading enabled (which sort of acts like a second core…) – that was the problem when I originally wrote this back in 2005 (we didn’t have multi-core CPUs then)!

  • Bruce
    Tuesday 24 March 2009 - 15:22 | Permalink


    Hi,

    I posted earlier that by doing what Mark and others suggested in this thread, I have been able to run FP26 on many different XP boxes – and again, I thank you for this. I have also had no problems with the Vista 32-bit system running foxprox.exe, and appreciated what a recent contributor said about using Start, affinity, etc. in a single command line.

    However, I am now trying to get FP26 to work on a 64-bit Vista workstation, and have not been able to yet.

    I also thought maybe I could use foxpro.exe using the Vista 16 bit parameters for the Start command (SEPARATE and SHARED), but they only work on 32-bit platforms.

    I also tried using the SysWoW64 subsystem but keep getting told that the FP26 cannot run in a 64-bit environment. (I thought running the SysWoW64 subsystem would allow for this.) This is what I did:

    Clicked Start button, then typed %windir%\SysWoW64\cmd.exe in Start Search box.

    Then I tried running FoxProx.exe to no avail. I get this error:

    “The program or feature “\\??\c:\fp26\fx.exe” cannot start or run due to incompatibility with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available.”

    (LOL, I don’t think I will contact MS about a 64-bit version of FP26. ;) )

    So if I can get Foxprox.exe to start, I can presumably then set affinity, etc.

    As always, any suggestions would be very appreciated. I understand I can install DOSBox and it was said to work with FP26 on a 64 bit Vista machine by a contributor elsewhere, but I was hoping to avoid a third-party layer of emulation.

    DosBox: http://www.dosbox.com/download.php?main=1

    Thank you in advance.

    Bruce

  • Bruce
    Tuesday 24 March 2009 - 18:04 | Permalink


    As a followup, I experimented with DOSBox and this program worked flawlessly – running Foxprox 2.6 for DOS under Vista 64-bit with no worries about setting affinity, etc. It also allowed full-screen display as well as adding to a config file for automatic drive mounting, loading foxprox, etc. I could not get my foxprox screens to hang no matter how much mouse movement I did.

    Since I am only using Foxprox.exe to make changes to various screens (which I then run as .SPRs under Visual Foxpro), I am not so concerned about speed. However, for what it’s worth, DOSBox was written with DOS gamers in mind, and since speed is an issue for gamers, DOSBox may still run your app fast enough.

    So if all else fails in 64-bit mode, have a look at DOSBox.

  • Tuesday 24 March 2009 - 18:22 | Permalink


    @Bruce – I think you might be pushing things just a little too far here, trying to run a 16-bit MS-DOS app on 64-bit Windows. As far as I can see, your 21st century options really are:

    1. Redevelop the application
    2. Desktop virtualisation
    3. Presentation virtualisation (terminal services)

    I suggest number 1 is the best path forward, with 2 or 3 as a tactical solution only!

  • Tuesday 24 March 2009 - 18:24 | Permalink


    BTW, DOSBox is emulation (rather than virtualisation, which is what I suggested in my comment a few minutes ago). You might get better performance with virtualisation – Microsoft Virtual PC is a free download for licensed Windows users.

  • Bruce
    Tuesday 24 March 2009 - 18:39 | Permalink


    Yeah, I agree with you Mark. Unfortunately some of my clients still want changes to their (originally DOS Foxpro) apps that I moved to VFP – but I did not change all the screens, because most of these clients did not want to pay enough to have all of their custom apps (screens) cut over to pure VFP. So if they need screen changes, I still have to revert to FP26 for that. Fortunately, only one of my clients still even run a DOS-based FP app, so this is much less of an issue now – except for the occasional screen modification for the others. (I didn’t want to change the many many hundreds of screens for free at the time.)

  • Tuesday 24 March 2009 - 21:27 | Permalink


    @Bruce – glad you found a working solution. Thanks for sharing it!

  • Friday 5 June 2009 - 17:31 | Permalink


    Thanks a million Mark, et al.! I had a problem that was completely unrelated to FoxPro, but was using a 16-bit application that I wrote a while back, and this fix to the ntvdm.exe worked like a charm! :)

    Note that I was able to fix this problem only with the following caveats:

    Initially, I was unable for some reason to get the “imagecfg -a 0x1″ command to work on any ntvdm.exe (kept hanging the imagecfg program), but I found that if I did a “image -u 0x1″ first, and then used the “-a” switch, that it worked for me.

    Also, I had to fix a temp copy of ntvdm and then copy and overwrite not only the c:\windows\system32\dllcache\ version, but also the c:\windows\ServicePackFiles\i386\ version before I could overwrite the main c:\windows\system32\ copy and get it to stick.

    Hope this helps anyone in my situation!

  • Thursday 11 June 2009 - 9:30 | Permalink


    Thanks man!!

  • Ian
    Wednesday 1 July 2009 - 0:16 | Permalink


    I have a FoxPro (ver 8) problem with pif files not functioning with my new 64 bit computer and Stata version 10.
    Can this be solved?
    Look forward to any help
    Thanks
    Ian

  • Ian
    Wednesday 1 July 2009 - 0:19 | Permalink


    Sorry that should be FoxPro Version8
    Ian

  • Wednesday 9 September 2009 - 9:00 | Permalink


    Try the Tao ExDOS, it will probably answer any DOS users needs on Windows XP,VISTA,7 and Terminal Server.

  • Carlos
    Friday 19 February 2010 - 3:48 | Permalink


    Hi All!!!

    Great post!

    Thanks so much Mark and You all for the workaround with this issue.

    I have used FPD 2.5 & 2.6a in XP Pro machines. The newest one with dual core, perhaps with HT enable also. Freeze randomly, and with a test hover mouse with command windows by about 30 seconds always!

    This solved my issue arise for a long time!

    Perhaps it´s time to switch to another technology, like .NET and focuses on OOP.

    FoxPro was a nicest technology, but that is history. That´s my two cents!

    cmf.

  • Sunday 27 June 2010 - 6:54 | Permalink


    Thank you Mr. Mark for solving my long pending problem with NTVDM. and also sharing a printer in DOS mode. Thank you verymuch.

    Jk

  • Wednesday 28 July 2010 - 8:53 | Permalink


    I received a email from Roger A Krupski with another suggestion for attacking this problem:

    “First, I set “DefaultSeparateVDM” in the registry to “Yes”. Then I use the imagecfg.exe tool, but instead of hard coding -a 0x1 in ntvdm.exe, I instead used -u to force NTVDM into uniprocessor mode.

    Now, when I run one old DOS app, NTVDM’s affinity is to CPU0. Next instance (while the first is still running) goes to CPU1, etc.”

    Certainly sounds to me like a better way of approaching this problem. Thanks Roger!

  • Dipesh Mehta
    Monday 9 August 2010 - 6:32 | Permalink


    Thanks a lot; Mark Wilson. A great and thorough study about the matter, such that it is still applicable after almost 5 years of your first post.

    I have few FoxPro 2.6 / DOS based applications, which I run on Windows 2003 Enterprise Server with Terminal Services alongwith some 12-15 Thin Clients. My server’s processor is Intel Xeon E5504 Quad Core. Its single processor server.

    I have been facing problem when there are some 4-5 simultaneous instances for the said applications running. I have followed your guide to set affinity but one of the FP application ends with error “NTVDM encountered Hard Error” while others run smoothly. I also tried to set affinity using ‘start’ as commented by Mark C (11 April 2007) but the same error.

    Almost similar configuration (only change is processor is Xeon E5310 QuadCore) and same programs at our branch office, now runs fine after configuring affinity.

    I googled for NTVDM hard error, but couldn’t find anything solving my problem.

    Please help me get rid of the error.

    Thanks in advance.

    Dipesh

  • Thursday 12 August 2010 - 16:22 | Permalink


    I am planning to use remote desktop connection to connect a network of XP systems to another set of XP Systems running my DOS Based (foxprox 2.6) multiuser POS package. In my trial run I am not getting full screen window of the application when remotely connected. Can somebody help me. ?

    Jk

  • Jenda
    Tuesday 7 September 2010 - 10:39 | Permalink


    Full screen is in text mode. This mode is not possible use over remote desktop. You set font size in cmd windows properties to maximize view.
    JK

  • Steve Goodwin
    Friday 10 September 2010 - 7:13 | Permalink


    I am trying to use the imagecfg tool to prevent FoxPro 2.6 DOS lockups as described above in many previous postings. However I cannot get the modified NTVDM.EXE to stick as it automatically gets restored. I have searched for every copy of NTVDM.EXE on the system and have replaced each one, but the one in C:\Windows\system32 keeps reverting.

    There is a C:\Windows\Prefetch folder that has a file called NTVDM.EXE-1A10A423.pf that I have tried renaming and deleting, but it also keep reappearing automatically.

    I have also downloaded RunFirst, but I cannot find any instructions for its use.

    I would appreciate any help or advice that is offered. Thanks.
    Steve

  • Jindra
    Thursday 11 November 2010 - 9:37 | Permalink


    Hi, can provide a link to download startHT.exe. According to the description of the program Runfirst against the possibility of routing to a specific core. For Windows XP, can not be used instruction “start” without the extension system. Best regards Jindra

  • Lee Binder
    Tuesday 25 January 2011 - 22:42 | Permalink
  • SEMAJ
    Thursday 24 February 2011 - 15:13 | Permalink


    Can I ask a question about FPDos in Win XP, Tamedos and numeric keypad behavior ; and where ?
    (support@tamedos.com does not answers … )
    THX
    SEMAJ (France)

  • SEMAJ
    Tuesday 8 March 2011 - 8:50 | Permalink


    no objection ; so :

    My question :

    Under Dos, Windows 98 (…) : FOXPRO DOS allows to toggle the numeric keypad, ON or OFF [ thanks to the function ‘NUMLOCK( )’ ; becoming ‘.T.’ or ‘.F.’ ]

    Under Windows XP with FOXPRO 2.5 for DOS (FoxProX) without TAMEDOS, this does not happen …

    TAMEDOS v.6 (only in full screen …?) enables this “software toggling” but the led of the numeric keypad does not “lights on” (does not turn on or off) …

    Nevertheless : in the ‘ Memory Frame ‘ of the ‘ TameViewer ‘ , the [ Key Flags ] and the [ Led ] informations toggle adequately, becoming ‘Num’ , ‘Caps’ …

    Would you have a solution (to light up the leds) ?

    Thanks.

    SEMAJ

  • SEMAJ
    Wednesday 9 March 2011 - 15:36 | Permalink


    Could be useful (if it works ?! ; ‘FOXPROX.EXE’ couldn’t be tamed before this …)

    ImageCFG GUI v1.1, small program to set CPU affinity ; at :

    http://www.shareseeking.com/ImageCFG-GUI-v1-1-small-program-to-set-CPU-affinity_146898.html

  • Judy
    Monday 18 April 2011 - 7:15 | Permalink


    Thanks Marks, really helpful. Nice job !

  • Sunday 19 February 2012 - 20:50 | Permalink


    I wonder if this problem persists on new version of FoxPro? I’ve had some random hangs from time to time that only seems to stop when I killed the process. The application would execute normally once it has started, but after some time it would hang without even a single input. I tried your method of setting ntvdm affinity processor and it worked out very well! If anyone is still struggling with this problem, read the post and apply the fix Mark used, it works flawlessly.

    Thanks Mark for saving me :)

  • Lukas
    Monday 20 February 2012 - 12:35 | Permalink


    Hi all,

    First of all thanks for the usefull information from everyone here. I still hope that someone will still respond on this thread because we have a similar problem in our company and i’m trying to solve it.

    We’ve had Windows 2000 server which had a FoxPro 2.5(a) application with many databases and client workstations all with Windows XP SP3. Everything was running fine, no freezes, crashes, etc..

    But i think that about one year ago we upgraded to Win 2003 server, everything else remains the same. Clients have mapped the server as the F: drive and run the FoxPro application from there (it is not executable, only a *.bat file which runs the program directly via command line). But since the upgrade it started to freeze randomly and also crash without any noticeable reason. Since the server is used by almost all employees i can’t mess around with the server a lot, so only thing i’ve tried is to disable the Hyper-Threading on it. And on my workstation when i run the FoxPro application from the server i see that the process ntvdm.exe (in the task manager) takes about 1,3 GB of memory!! Also i’ve manually set the affinity for this ntvdm.exe on my workstation to only CPU0, but with these two mentioned changes it still freezes randomly!

    Is there something i didn’t understood clearly? Any advice would be really helpful!
    As you can see – still in this year some companies are running the old fashioned FoxPro.. and guess the reason? – money –

    So any suggestions to this problem would be really appreciated.

    Thanks!

  • Jose
    Thursday 1 March 2012 - 21:19 | Permalink


    I found a problem (DOS aplication freeze after a minute or so) in a motherboard with a parallel port (enabled in setup, but without printer conected to it). When the port was Disabled, the problem is gone.
    I hope this hint can help.

  • Jarek
    Friday 23 March 2012 - 13:43 | Permalink


    Thanks to Mark and especially to Alex for his vaffinity which really looks to me as the most “simple & elegant solution”. (It fixes a problem with some clipper app on Win7.)

  • Jenda
    Wednesday 9 May 2012 - 10:55 | Permalink


    ntvdm from media center XP is ok for FoxPro for DOS

  • Jean Denis
    Thursday 17 May 2012 - 9:20 | Permalink


    Hi.

    I undersatand that the trouble I have with Win7 is a new version of an old one.

    I keep using PARADOX DOS in a dos window. Since Win95 Me and XP, it was running Ok.

    After updating my pesonnal PC from XP to 7 it was running also.
    Now when I want to change window by Alt+Tab, the screen turn black until I stop the
    program by task manager.

    I will try the suggestions above unless you have a better idee, and keep you informed.
    regards
    Jean Denis

  • Anonymous
    Tuesday 11 September 2012 - 9:46 | Permalink


    I’ve been using Util.bin and VAffinit.dll with an FPD2.5 application to set the process affinity to 1 CPU from within FPD under XP and W7. This is working without freezes on about 800 installations (although some are still W2k, which does not have the problem). Afaik, the problem only occurs if you are using the Extended memory model, so limiting your FPD2.5/2.6 app to Dos 640k memory is a quick way of avoiding the random freezes without modifying the code. The app here is a memory hog, so I needed to implement the FoxPro Extended version and set the affinity to 1 cpu.
    Util.bin/VAffinit.dll is Public domain, developed by Tomáše Chvátala, EZOP Praha s.r.o.. It notice that his original download link is broken, but you should be aple to find it by searching for foxsetaff.zip.
    Hope this helps. Ian Pringle, Brussels.

  • Anonymous
    Thursday 22 November 2012 - 19:30 | Permalink


    I recently had this problem (CPU NTVDM problem when try to run a FoxPro app on Windows XP), and the solution was very simple. Delete de autoexec.nt and config.nt and replace it with original, on C:\Windows\repair. very very little differences had, but it works! Hope to help. WillyG00

  • Wednesday 2 January 2013 - 8:21 | Permalink


    ” Delete de [ the ?? ] autoexec.nt and config.nt and replace it with original, on [ from ?? ] C:\Windows\repair. very very little differences had ”

    What does it mean exactly ?

    Regards
    SEMAJ

  • V.V.N.Ratna Kumar, 41-17-31, Dintyalavari Street, Krishnalanka, Vijayawada-13. +919848125625
    Friday 5 July 2013 - 13:56 | Permalink


    ThanQ Sir, with your guide lines my application designed in foxprox 2.6(dos), running succesfully in windows 2008 server

    once Again Thank Q

    Regards
    V.V.N.Ratna Kumar
    India

  • Monday 8 July 2013 - 22:04 | Permalink


    I’m glad that post is still helping so many years on!

  • Don
    Wednesday 30 October 2013 - 1:21 | Permalink


    Most interesting reading. My issue with NTVDM.EXE was concerning a compiled
    Basic application I wrote some time ago. NTVDM was getting 99% CPU use and
    hanging there for several seconds, long enough to be frustrating as the app
    normally just runs without hesitation. I run three instances simultaneously
    on a single core Celeron running at 3.06GHz.

    Following the tip from Anonymous Oct. 20, 2006, I back dated NTVDM.EXE to version 5.1.2600.1106 which I found on another XP box I wasn’t using. NTVDM still goes to 99% CPU
    utilization on CR execution but quickly drops back and allows the CPU to recover. Version 5.1.2600.1106 may have been SP1a, I don’t know. I used Puppy Linux to replace the files in system32 and servicepackfiles\i386 without any issues. Sometimes one just wants to keep using the old stuff.

  • Petar
    Friday 31 October 2014 - 16:44 | Permalink


    @Mark “I’m glad that post is still helping so many years on!”

    Yes, that’s true.

    Thanks a million, Mark. I have many old (POS, EPOS, accounting) Clipper apps (which I even upgrade here and there :) ) that worked for years (from 1992.) on DOS, Win95, Win98, Win2000, Win XP (all 3 SPs) without any problem.

    On Win 7 (Intel i5 or i7) it just hangs after some time, usually 5-10 minutes, after some computation. I was desperate. I really tried many solutions and tried to solve it, but nothing worked.

    Only your solution (and advices from many others here) completely solved my problem. And I accidentally bumped to your site.

    I use a desktop icon with properties’ Target: C:\Util\CMDRUN.BAT 1

    Contents of C:\Util\CMDRUN.BAT:
    @echo off
    c:
    cd \
    C:\Windows\System32\cmd.exe /c start “DOS %1″ /AFFINITY %1 echo DOS %1

    I also have 3 other desktop icons with properties':
    Target: C:\Util\CMDRUN.BAT 2
    Target: C:\Util\CMDRUN.BAT 4
    Target: C:\Util\CMDRUN.BAT 8

    User can open any of 4 dekstop icons or all of them. Each one is using different core: 0, 1, 2 or 3, and can then run DOS app from command prompt (for example, entering pos.exe or just p (calling p.bat that runs pos.exe)).

    It works like a charm.

    p.s. I tried various virtualizations, and they all seriously slow down my program, almost to an unacceptable level. Dosbox is also unusable to me, because I send mail from my program (Blinker SwpRunCmd, much better than Run) or export dbf to Excel and then run Excel and return back to program like nothing happened, and Dosbox is pure dos. It can’t do that.

    p.p.s In the meantime I migrated to python which is in my opinion most similar to our xbase family languages. With python, I now live a second life. I write programs in it like in old days with dbase, clipper, foxpro or xbase++ and I recommend it sincerely.

    Thanks Mark, you saved me.

    Petar

  • Leave a Reply

    %d bloggers like this: