NTVDM.exe

[redwolfe_98]

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?

[Bowserman]

Hi redwolfe_98 :).

Yes, it is added/protected by ProcessGuard as a default.

-{ Quote: "ntvdm - ntvdm.exe - Process Information

Process File: ntvdm or ntvdm.exe
Process Name: Windows 16-bit Virtual Machine

Description:
ntvdm.exe is process that belongs to the Windows 16-bit Virtual Machine. It provides an environment for a 16-bit process to execute on a 32-bit platform. This program is important for the stable and secure running of your computer and should not be terminated.

Author: Microsoft Corp.
Part Of: Windows

System Process: Yes
Background Process: Yes
Uses Network: No
Hardware Related: No
Common Errors: N/A" }- - source (http://www.liutilities.com/products/wintaskspro/processlibrary/ntvdm/)



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

[earth1]

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.

[gottadoit]

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)

[earth1]

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.

[zer]

Maybe this info about ntvdm.exe (http://www.2-spyware.com/file-ntvdm-exe.html) will help.

[gottadoit]

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 :)