is "ntvdm.exe" a process that is "protected" by PG, by default? is it one of the items that is included in pg's "protection", by default?
Hi redwolfe_98 . Yes, it is added/protected by ProcessGuard as a default. - source Here is a screenshot with the defaults in case you need to restore them . Regards, Jade. EDIT: Added a bit of info on ntvdm.exe
I am leary of ntvdm.exe because it seems similar to rundll32. When PG asks permission to run ntvdm, it's actually some "client" code that wants to run (in this case a 16-bit program). Unlike rundll32, though, PG does not even show you the associated command line which means you have no idea what will run. And while ntvdm may (or may not) be capable of keeping clients sandboxed away from the real (32-bit) world, a 16-bit program would still be capable of deleting all your data files at the very least. I would recommend keeping ntvdm.exe set to "Permit Once", and if it pops up for no apparent reason, I would not let it run. I've also removed authorization to Read/Modify protected programs, just in case the sandbox develops a leak. You should also be aware that if you run a 16-bit program from a DOS window, the ntvdm.exe process remains actively attached to the DOS window that started it, even after its16-bit client has terminated. If that same DOS window wants to start another 16-bit program, PG won't see it happen. A16-bit program that has never run on your system could run without PG giving any alert whatsoever. This is also true for the UNIX-like command line that I use every day (and probably for any console app that starts a 16-bit program). For this reason, I try to avoid running any 16-bit programs from a console window. After you approve just one, you're totally unprotected from all others. By contrast, a 16-bit program run from Windows Explorer is somewhat safer, because the ntvdm.exe process will terminate immediately after its client does.
There were always going to be other programs like rundll32 to add to the list, I guess this counts as #2 It is probably worth adding a comment to Andreas1's sticky thread about this, the fact that ntvdm persists for the life of a cmd window is not something that everyone will know By the fact that nobody else has commented previously, I'd have to guess that not many people have tried to observe the behaviour when 16-bit programs are run Thanks earth1, I will be putting ntvdm.exe on my deny always list seeing as it hasn't been run on this PC at all and the process hanging around for the life of a cmd window doesn't really fit with the security approach I am using here As a side issue it might be worth considering upgrading your old 16-bit software... (is it an aging MKS toolkit version by any chance?), if so then there are freeware unix tools that are almost as good (if not very similar)
I think you're right, I should just rid my system of 16-bit utilities and set ntvdm.exe to Deny Always. Thank goodness that I do have a 32-bit version of (you guessed it) MKS toolkit. It may be 10 years old, but I'd hate to give it up.
For the little that it is worth I came across this registry entry by chance HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW\DefaultSeparateVDM By default it is no, and when changed to yes, and the PC rebooted Then a new ntvdm.exe should be spawned for each 16bit application and that should cause PG to display an alert [NB: I haven't tested it... ] This might cause compatibility problems for some applications, but if you are still running 16 bit applications like this you may well be used to the odd issue here and there
