OA4/WIN7 The NTVDM CPU has encountered an illegal instruction.
 

Hallo Ludwig :-)

Jetzt macht er mir zb. diesen Fehler in Win7.

Nachzustellen ist der Fehler recht simpel - einfach aus dem OA4 heraus per F8 den DESK MANAGER starten und die Eingabeaufforderung aufrufen. Dann ein simples DIR starten und nach Rückkehr (EXIT) ins OA4 per ALT+TAB ins Windows wechseln. Schwupps - schon hat man einen dunklen Bildschirm (für ca. 30 sek.) wo man denkt der Rechner hätte sich verabschiedet....

Tja, ist leider ein Windows 7 Problem. Da kann ich auch nicht viel machen leider.
Deutet sehr auf den Videotreiber hin.
Siehe hierzu auch: http://www.experts-exchange.com/Micr..._22391981.html
Nachdem wir ja wissen, dass Microschrott die Videotreiberunterstützung in Vista schon ziemlich ruiniert hat (ich sag nur Vollbild), liegt die Vermutung nahe, dass NTVDM nun nichteinmal mehr 100% mit dem Standard VGA-Treiber kompatibel ist.

Allerdings habe ich zu demselben Fehler öfters schon gelesen, dass man die TEMP und TMP Environment-Variablen auf ein Verzeichnis setzen sollte, welches einen kurzen Standard DOS-Dateinamen enthält, vielleicht hilft das ja wirklich was? :confused:

Sonst hilft wohl nur Beschwerdemail an M$ schreiben, warum sie immer alles kaputt machen müssen oder einen eignenen DOS-Emulationslayer wie DosBox verwenden. Andernfalls muss man leider mit dem Problem leben, wenn man unbedingt mit Windows >XP arbeiten will :mad:

#unhide (This post can be viewed by guests also)

Hallo !

Ich hab mir das Problem jetzt doch mal näher angesehen und einen Patch dafür gemacht, nachdem M$ leider noch immer säumig ist.
Nachdem er nicht nur deutschsprachige OA-Benutzer interessieren könnte, habe ich meine Erklärungen dafür auf Englisch geschrieben...

Analysis and fix for the fullscreen switching bug in Windows 7
================================================== ============

You may already know that ALT+Enter is a commonly used hotkey to switch
application between window mode and full-screen mode. For the cmd prompt,
the hotkey should work as expected on prior windows OS up to windows XP
and for example enters real Text mode for DOS applications.
But for Windows Vista and Windows 7, cmd can't be switched to
full-screen mode, this is by design.
For further information see http://support.microsoft.com/kb/926657
There is a very interesting article explaining the rasons behind this,
which I recommend you to read:
http://colinxu.wordpress.com/2011/02...ssue-analysis/

Now it's also known and explained in the KB-Article, that you can get
back fullscreen with either a WDM-driver for the Windows XP display driver
model or to switch back to the default VGA video driver, which still
supports the old driver model.
This works, but there are some issues that users experienced, most notably
a bug in the Full screen switching code that causes a NTVDM lockup which I
will cover in this article.

How to enable Fullscreen for your DOS apps
==========================================
But first, how to conveniently use DOS Fullscreen applications without the
need to be stuck with the VGA driver all the time?
The preferred method is to install the XPDM display driver for your graphics
board, but if this doesn't work, I also have a very convenient solution.
So each approach is described here:

Installing the XPDM driver for your video card
-------------------------------------------
First, check if there is a Windows XP videp driver available for your graphics
board. You need to have the driver installation (.inf) files available, so
it won't help to just have an .exe Installer, because most likely this
installer checks for the OS version and refuses to run on Windows 7.
So in case you just get an .exe, you first need to extract the .inf
and .sys files from it, i.e. via 7-zip. Here is a thread describing how to
extract Intel video drivers for instance:
https://communities.intel.com/thread/12591
After you have the .inf files, you need to check if they contain a section
for Windows 7 or if the refuse to run there.
Intel Video drivers i.e. have this section:

As you can see, there is a section for Win7 (IntelGfx.NTx86.6.0), but
it doesn't contain any entries. So simply copy all the PCI strings
from Windows XP section (IntelGfx.NTx86.5.1) to this section
(just place the entries right under [IntelGfx.NTx86.6.0] line.

After fixing the .inf file, go to the Devie manager, uninstall the
WDDM driver and update the driver to the XPDM driver by pointing
the installation source to the diectory you have your .inf file in.
If everything works, it will detect and install the XP driver and if
you have luck, you are then running the XP driver which supports
fullscreen.
If you fail or are unabe to do this, please consider the following
option instead:

Using Fullsreen by dynamically switching between VGA and WDDM
---------------------------------------------------------------
Note: This is just meant for users that don't have a Windows XP Display
driver available for their Video card, using the XP Video driver is still the
preferred method as it saves you don't need to switch between the
video modes as described here. However the XPDM display driver may
have performance issues, so you can decide which works better for
you.
In Windows 7, you can dynamically enable and disable the video driver
without reboot, which is great because this way, you can also script this
and therefore make a batchfile, which disables your current WDM video
driver so that you have the standard VGA XPDM video driver, then
switch to fullscreen, use your DOS app and after you are done
restore the WDM video driver with devcon.
I made a patch that automates this for you which can be found here

Otherwise here is how to do it:
* Download devcon [http://support.microsoft.com/kb/311272] and place
it in your application directory, i.e. C:\OA4
* Put my Fullscreen switch utility (fullscr) attached below into your application directory.
* Now create a batchfile to start your application, i.e. STARTOA4.bat with
the following content:

------------------------------------------------------------------------------
------------------------------------------------------------------------------
You obviously have to adapt OA4.EXE to the application file for your application
to start (i.e. you may have a batch file to start, then use "call mybat.bat"
so that the startoa.bat isn't quit) and the "cd" at the beginning to go to your
application's directory. This is
necessary, as all Batch files that are run as admin via a link start in
%SystemRoot%, so you have to go to your dir first.

* Now as devcon is messing around with the system hardware, it needs
Administration rights to do its task.
So you now should create a shortcut to STARTOA4.BAT, i.e. on your desktop
and in its properties under "Advanced..." select [x] Run as administrator.

Done, now everytime you click your shortcut, video mode is switched to standard
VGA, then your DOS APP is run in fullscreen and
after exit, VGA card driver is restored back by enabling it. The fullscr 2 command does a switch back to windowed mode [fullscr.exe was updated on 2016/10/13 to support this], as some WDDM video drivers crash when switching back from textmode directly when reenabling.
I hope it works for you.
Don't forget to change the video resolution when in Standard VGA mode to
your normal resolution, as it's usually impractical to be stuck at 640x480
and even the Standard VGA driver normally supports higher resolutions,
but default is 640x480 when you disable your WDDM Display driver for
the first time.
As you now have the possibility to run your application in full screen text
mode, now let's go for the bugs that you are facing.

The Fullscreen NTVDM Bug
========================

Just try the following to reproduce it:
Just run your favourite DOS program in full screen mode, either by using
the trick mentioned above or by generally running in Standard VGA mode
and editing the settings of your favourite DOS program to switch it to Full screen
(Properties of .EXE -> Screen -> change from Windowed to Full screen) so that
it starts in full screen mode. Also ensure that you enabled the possibility to
capture ALT+Tab for switch (default). When the DOS App starts in Full-screen,
try to switch away with ALT+TAB and boom, your machine keeps hangig for almost
a Minute, afterwars you are back in the GUI mode and have a message box telling
you "NTVDM has encountered a system error. The parameter is incorrect".
This is especially naughty combined with the bug that the guy in the blog
mentioned above found. Once you switched to VGA and back to the driver,
Fullscreen is not blocked and therefore you also get into this lockup trouble,
once you notice that the mode switch went wrong and you want to go back
(i.e. by pressing ALT+RETURN again).
So that's pretty annoying, of course, so time to debug this issue.

It's not easy to find, as you can't have your debugger open while in full
screen, so I attached the WinDbg kernel debugger to the COM port and tried
to debug a usermode application with it.
Let's see where it hangs in ntvdm:

The last thread is interesting to us, it hangs at GetConsoleScreenBufferInfo
when waiting for a LPC message. We have to consider the new console
architecture of Windows 7 which is very well explained here:
http://blogs.technet.com/b/askperf/a...sole-host.aspx

There now is a seperated Usermode process called ConHost.exe that hosts
a console. It is talked to by a LPC call. So NTVDM is asking ConHost about
GetConsoleScreenBufferInfo, but ConHost.exe is not replying causing the hang.
That means we have to debug ConHost and check where it locks up:

Seems like both threads have a deadlock condition, so time to take a closer
look on it. First interesting up in the stack is LockConsole:

So there is a global Critical section object for the lock.
RevalidateConsole just calls LockConsole and always returns 0:

Now let's have a look at ConsoleWindowProc, which is calling DisplayModeTransition:

So the global lock is being held by ConsoleWindowProc when calling
DisplayModeTransition. Now let's check DisplayModeTransition: where it
hangs:

As the function is quite long and a bit complicated, let me wrap this up for you as
stripped pseudocode to better understand what is going on here:

First thing to notice: As seen above, RevalidateConsole always returns
0, that means that the first IF path is always taken and the rest after that
path will never be reached. That dead code is a good place that can be used for
a patch lateron.
What is interesting are the functions UnlockConsoleForCurrentThread and
LockConsoleForCurrentThread:

So gConsoleInformation.RecursionCount gets returned and if there are
Recursions, the console is Unlocked the number of recursions given.
Now the counterpart LockConsoleForCurrentThread:

So it calls LockConsole for the given number of recursions, unless it's
already locked. In the above code, it's adding back the number of
recursive Locks that were taken and released prior to
NtWaitForMultipleObjects() call.
Fine so far, but there also is a call to RevalidateConsole() which does
a LockConsole internally as seen above. This doesn't hurt, as LockConsole
only adds locks, if there are too few, but as RevalidateConsole()
already adds the missing lock, it doesn't do anything. As there is
already a lock from the ConsoleWindowProc in place, the call to
Revalidateconsole() is unnecessary, as LockConsoleForCurrentThread() will
also be able to add the missing lock itself.
Its return values are of no use either, as the code branch is never taken.
So this call is another thing that can be eliminated. -> Even more space

Now where does the deadlock finally happen?
It's the NtWaitForMultipleObjects call after ConnectToEmulator(), so my
assumption about what is happening here is the following:
Normally there is always one event queued to the VDM, then the event
hObject is signalled to actually run the task in the VDM and then it's
waiting for the VDM to complete the task by waiting on the wait-handles
via NtWaitForMultipleObjects. Now one of these tasks calls
GetConsoleScreenBufferInfo (As seen in the stack above), which in turn
is waiting for the lock. As the lock is actually being held by the
ConsoleWindowProc --> DEADLOCK!!

Now it seems that this may be expected so there are the
UnlockConsoleForCurrentThread and LockConsoleForCurrentThread functions
that temporarily remove the lock to prevent such situations while
waiting for the console to execute the requested task and afterwards
immediately place a lock on it again. But this is only done on the first
Wait-call and the deadlock-Condition actually occurs on the third
NtWaitForMultipleObjects call. These code blocks are only used for NTVDM
processing anway (as they are guarded by CONSOLE_VDM_REGISTERED flags),
so I guess this was just a programming error.
So this leads us to a strategy for fixing:

How to patch this deadlock
==========================
The simplest solution would be to just eliminate all the locking calls
and just leave the UnlockConsoleForCurrentThread call so that there are
no locks to wait for. This indeed works, but doesn't look like a proper
solution. When having a look at the way the NtWaitForMultipleObjects
function is called in all 3 places, it can be seen that it's always the
same call and it's always using the same variables. This gives us the
opportunity to reuse the existing calls to it and just add a wrapper
with UnlockConsoleForCurrentThread before and LockConsoleForCurrentThread
afterwards so that it's "guarded" by the Mutex releasing functions.
In pseudocode, we would replace all NtWaitForMultipleObjects calls with:

To see how this can be accomplished, have a look at how this Sequence
is implemented in the ASM-code:

Now let's also have a look at the other places in the code, that call
the NtWaitForMultipleObjects function (only those who are used that have
gConsoleInformation_Flags set to CONSOLE_VDM_REGISTERED (0x200), as
only they are relevant for Fullscreen handling):


It can be seen that the code for calling it is always the same.
So the first function that does the locked calls can be rewritten to
immediately lock again after the wait and reused in all functions.
Be aware that the code is a minefield full of relocations because of the
many globals that get used and these places cannot be overwritten with
our code without removing them from the relocation table. On the other hand,
code that is necessary and contains relocations shouldn't be removed as this
would also require touching the relocations. Therefore a solution is needed
that just fits in place.
So here is my solution to this (see comments for details)

Now the CALLs to Wait function get substituted like this:

Same here:

So finally this is now fixed, as M$ doesn't seem to care.
Btw.: CONHOST issues some debug messages, if you attached a kernel debugger,
you can use the command

to enable tracing these messages.

Why is this not happening when starting the console in windowed mode?
================================================== ===================
As we have seen in the stack trace at the time of deadlock above, there are
some functions on the stack that finally cause a call to
GetConsoleScreenBufferInfo API which causes the deadlock. So let's trace
down the function calls on the stack and compare the execution flow to
see where it differs between start in full screen and start in windowed
mode (and then sithcing to fulscreen).
The function in nt_init_screen+0x1ce seems to be good candidate, so let's
trace it. Let's have a look at the function s a whole first:

A lot of compares in there! We know from the stack trace above that it hits
0e5e23c9 e8e4fcffff call ntvdm!textResize (0e5e20b2)
when starting in full screen mode. So now trace the function in windowed mode:

The function should hit 0e5e23b6, but it never does.
Let's have a look at some pseudocode again:

So it seems, that everything is equal already (text size already calcualted?)
when starting in windowed mode, but when starting in full scren mode, there
seems to be a difference:

So that's the reason for this. From my point of view, it's still the fault of
conhost not to permit calls from NTVDM while it's processing some requests.

The patcher
===========
I wrote a little patcher that applies the patches and hopefully works for every
released version of conhost.exe on Windows 7.
Just download the patch and run it as administrator and then check if the bug
is fixed. I'd love to hear from you if it worked for you too.

The file can be downloaded as unregistered member from here:
http://www.waldbauer.com/tmp/reference.php?

#unhide (This post can be viewed by guests also)

NTVDM Fullscren Issue #2
========================

Today I noticed another problem with the NTVDM Fullscreen handling in
Windows 7. I can't call it a bug, as it's by design, but it's an annoyance
anyway. When running DBASE for DOS, I noticed that switching between
windowed mode and Fullscreen in some cases took 5 seconds to react which is
very annoying and gives the impression that the NTVDM got stuck.
This issue is not with all DOS-applications, but it can be reproduced with
DBASE.

This time, it's not CONHOST which is at fault, but it's NTVDM itself.
When attaching WinDbg to the failed process, the following Stacktrace can be
seen (we already know this one from the CONHOST bug..):

So it's stuck at the first WaitForMultipleObjects call in ntvdm!DoHandShake:

As can be seen, there are 2 handles being waited on:
ntvdm!hErrorHardwareEvent and ntvdm!hMainThreadSuspended with a timeout of
5000ms (1F4h). Bingo!
Now obviously normally the hMainThreadSuspended needs to get satisfied, we're
not keen on a handshake error. If the wait times out (return value is
WAIT_TIMEOUT=102h) then a Wakeup-call to the Monitor in the kernel, which is
responsible for the V86 execution of the program is being sent via NtVdmControl
and then there is another Wait for 60 seconds (927C0h) this time.
This gives us a clue where to search for where the necessary condition is being
set:

So there are multiple calls to ntvdm!CheckScreenSwitchRequest in cpu_simulate
of the NTVDM, which is the trap handler for V86 execution.

So we finally get the idea what is going on here:
NTVDM is assuming that the hosted DOS application generates some traps that
cause it to return to the cpu_simulate thread which in turn checks for
HandshakeInProgress in multiple places. If the is is set, it suspends
execution of the DOS application and the signals success by setting the
hMainThreadSuspended event which in turn releases the Wait-condition in
DoHandshake and let it continue its screen switch routine. After that the main
thread can be resumed and DOS-application is happy to continue its execution.
But if the application like DBASE isn't doing any traps, the Wait-call runs
into its 5 second timeout and this causes it to finally wake up the V86
MONITOR in kernel via NtVdmControl syscall and then finally the event gets
trapped and everything continues as expected.

Now why didn't this occur i.e. in the Windows XP version of NTVDM?
When looking at the DoHandshake() code in there, it just does a normal
SuspendThread(MainThread); in there and everything is working flawlessly.
Why M$ decided to change this behaviour is unknown to me, I guess only their
architects can tell us.

So this time, it's not a bug, but I think the timeout of 5 seconds is a bad
choice and a bit too high and therefore causes annoyance to the user.
So let's change it to another value, i.e. 500ms which looks fair considered
the fact that there is a wakeup-call to the Monitor in case of timeout anyway:
Search for

in NTVDM and replace it with i.e.:

for 500ms.
When patching ntvdm in Windows\System32 directory, ensure that you have
permissions to do so, so doing

before.
Of course, you can also use a little patcher that I wrote for your convenience:
Just run ntvdm_pat.exe to patch your Windows 7 NTVDM to 500ms timeout.
If you want to use a different timeout value, please pass the desired value to
it on the command line, i.e. if you want to use 200ms timeout, run:

This should fix another annoying behaviour of Windows 7 NTVDM for people who
for whatever reason cannot stick with Windows XP (i.e. because of a lack of
drivers).

Direct download: http://www.waldbauer.com/tmp/dl.php?download=ntvdmpatch

NTVDM fullscreen and startup issue with VGA BIOS of Intel video cards
 

What is it
----------
Short version:

Long version:
Recently I bought a new Mainboard with an Intel 4600 Onboard Graphics adapter
card. When starting the NTVDM on this machine, I encountered a 5-10 second
delay on NTVDM startup. But that wasn't all, things got even worse when trying
to switch to Textmode Fullscreen. The character output was 1 char/second,
which is obviously an unacceptable speed.
So I researched the Internet and found 2 threads in the product forums of
Microsoft and Intel:
https://social.technet.microsoft.com...itproappcompat
http://communities.intel.com/message/234383

Microsoft didn't care to answer to the problem at all and in Intel forums
someone from Intel just answered that their boards were not tested for 16bit
compatibility and therefore they don't care about the problem (which I cannot
really believe, as if that would be true, text output in BIOS or Linux console
would also not work properly).
Some people in the Intel-forum reported that they now had to order a bunch
of new graphics cards just because of this bug!
The sheer ignorance of both companies regarding this problem really upset me
and so it was my turn to investigate the problem and fix it, like many times
before :(
First, I needed to find out whom to blame for this mess. Intel or Microsoft?
Interestingly, they are both to blame in a certain way, but a problem with
NTVDM suprisingly is even benifical for solving the Intel video BIOS bug.
Sounds a bit confusing? You can read more in the technical details below.
Microsoft's fault is to not implement IN/OUT on 32bit Ports in NTVDM. But
even if that had been implemented, Intel's BIOS wouldn't work properly, it
would even cause more problems. Intel on the other hand expects MMIO ports to
be accessinble which isn't the cause in a V86 environment like the NTVDM.
Therefore it runs in a 1 second timeout on every operation, even though it
seems to work fine without using these MMIO-Ports. So their fault is to
try MMIO access for 1 second each time instead of just skipping over it if it
fails for unknown reasons.
The problem in fact can be solved by jumping over the check routine, which
is just 1 byte to patch in the Video BIOS.
Fortunately the NTVDM mapping of the BIOS address space can be patched in
memory via a NTVDM extension DLL, so that you don't need to reflash your VGA
BIOS.

System Requirements
-------------------
Should work on any Windows-PC with affected Intel Onboard Graphics board and
NTVDM.

How to Install
--------------
Go to the bin-Directory, right click on intelvidfix.inf and click install.

How to Uninstall
----------------
Open command shell as Administrator (rightclick on Command Prompt in
Start/Programs/Accessories, Run as Administrator)

Go to bin directory and then:
Technical details
-----------------
Now how did I find out what was going on here?
Obviously it was a problem with the Video BIOS, as the real Video BIOS only
gets executed when the DOS application is running in full screen mode,
otherwise it just BOPs to the VGA emulation of the NTVDM for windowed
mode. So we know that INT 10h is responsible for doing Video IO.
Therefore I traced through a simple call to INT10h for outputting a
character with the excellent DEBUGX.COM utility from the FreeDOS project
which in contrast to
Microsoft's classic DEBUG.EXE also supports 32bit code like used in the
Intel VGA BIOS and many new BIOSes lately. I cut out the register content
view on places where it's not interesting for a better overview:

So first of all, what is this dubois Port at F000?
According to 2nd Generation Intel Core Processor Family Desktop Datasheet,
Vol. 2 - Section: Device 2 I/O Registers:

F000 is the MMIO Address Register
F004 is the MMIO Data Register

They are specific for the Intel-Board and are not available to our NTVDM
emulation and therefore cannot be accessed, always returning FF on read.
Now first thing that comes to our mind when just seeing the loop that loops
for 1000 times is why the VGA BIOS is assuming that these non-Standard
I/O ports are there and causing a loop for 1000 iterations for every read
attempt. That doesn't look very smart and is the cause for the huge delay.
But then we can see that it's actually checked above if these ports are
there and if not (so if EAX is FFFFFFFF), they are not used and code should
jump over. This should theoretically be the case, except that the IN to the EAX
register just fills the lower AX register and leaves the high word of the
register untouched. So this leads us to believe that this is a NTVDM problem
and not a BIOS bug.
When digging through the NTVDM, it can be seen that they just didn't implement
IN/OUT for 32bit registers but just 8 and 16 bit. I even made a patch for
NTVDM to support 32bit IN/OUT (yes, it's possible to patch it in order to
do so, if you are interested in the patch, just contact me), but then I
realized that this maked things even worse. Why?
Because of the destination of the Jump, if the check for FFFFFFFF succeeds:

This jumps to the END of the interrupt routine so in this case it doesn't
do anything at all!
From testing the application in fulscreen operation, I was able to see that
it currently does its operations very slowly, but it does them fine. So the
correct way to fix this problem is not to teach NTVDM how to handle 32bit
IN/OUT port access, but instead just JMP out of the loop with the 1000
iterations and tadaa - Startup delay of NTVDM is gone and fullscreen
operations work normally!
So we just change:

to

In order to accomplish this, a litte DLL is generated that is loaded as a
VDD (Virtual Device Driver) for NTVDM. Memory for the VGA BIOS is mapped at
address C0000 in process address space and is mapped R/W, so DLL can access
memory there and just change 75 to EB and done.
So I don't know if the address layout of all the Intel VGA BIOSses is the
same as mine, I also impemented a pattern matching scan that searches the
VGA BIOS area for the asm code ocmbination at this place and tries to patch
it if pattern is found. I don't know every Intel VGA BIOS, I just had the one
from my card, but for this it worked fine.
If it doesn't fix it for your card, just send me an e-mail and I will give
you instructions how to dump your VGA BIOS so that I can analyze it and
update my patcher to also work with your VGA BIOS version.

For further information, just contact me.

Direct download (no registration needed) -> http://www.waldbauer.com/tmp/dl.php?...ad=intelvidfix

NTVDM mode switching bug in some NVIDIA GEFORCE VGA BIOSses
 

#unhide (This post can be viewed by guests also)

First of all, please check if this doesn't remedy your problem:
http://www.volny.cz/martin.sulak/
Download-Link for the driver: http://web.archive.org/web/200512240...k/videoprt.zip
Only use my workaround if this drivers doesn't work for you like it finally did for me!
My patch only makes textmodes work whereas above mentioned patch should also enable other video modes, as it fixes the root cause of the problem.


What is it
----------
Short version:
A patch that fixes a problem with some Video BIOSses on textmode switching
(INT 10h Function 0) when running in the Windows NTVDM on fullscreen
(this also affects Windows XP NTVDM!).

Long version:
Some years ago I bought a NVIDIA GEFORCE PCIE Graphics card that supported
VGA, SVIDEO and DVI output, as I needed all of them. The card worked fine
except for one strange behaviour: When I tried to start a DOS application in
fullscreen, it immediately crashed back to Windows.
And when starting a DOS application from a fullscreen console, the screen
just went blank and the application seemed to be stuck.
I was able go back to windowed mode with ALT+RETURN, but then the application
that I started had quit.
When attaching a debugger to the NTVDM, I saw that the VGA BIOS code crashed
on mode change!
As this seems to be a generic problem with various NVIDIA GEFORCE BIOSses I
decided to fix this by writing a TSR that hooks INT 10h function 0 and does
the classic port I/O necessary to do a mode transition at least in text modes
2 and 3, which are most common for textmode applications.
This lets me run textmode applications on cards with the flawed VGA BIOSses
again and may be useful for other users experiencing the same issues on their
graphic cards.

System Requirements
-------------------
Should work on any Windows-PC with affected Graphics board and NTVDM.

How to Install
--------------
1) Copy FIXTMODE.COM from the bin directory to your Windows\SYSTEM32 directory
2) Edit AUTOEXEC.NT in your Windows\system32 directory and add the command

very early in the file so that it gets loaded before other applications.

How to Uninstall
----------------
Edit AUTOEXEC.NT in your windows\system32 directory and remove FIXTMODE
command. If you want, you can also delete FIXTMODE.COM from your system32
directory again.

Compiling
---------
The Assembler sourcecode of the utilities is in the SRC directory.
You can compile them using Borland Turbo Assembler (TASM) with:

Technical details
-----------------
The installation of the INT10h handler is a bit of a problem, because
it cannot "forward" the Mode switch commands down the chain as this
would call original Video BIOS which crashes.
Normaly we would just install ourselves as INT10 handler BUT NTVDM
works windowed and fullscreen. Therefore it has its own INT10h dispatcher
which should be called and in turn calls Video BIOS.
So we have to update its pointer to Video BIOS function in order to
not mess up windowed operation of NTVDM.
In my copies of NTDOS.SYS in XP, there is a JMP (EA) at ES:951 to the
original video BIOS. In Windows 7, it'S at ES:969. In case it's not
changed, in subsequent versions of NTVDM, we can overwrite it.
The code has a fallback to do a INT 10h hook if it fails to find the
address at the specified offsets so that it still works at least, but
windowed operation is flawed then. If this is the case, please report this
to me and which version of NTDOS.SYS you are using.
One interesting thing to also note is that we don't need to waste memory
for the tables with the VGA controller settings to be used to switch
to textmodes 2 and 3 as these tables are already present in memory at
the beginning of the NTDOS segment. It's called "baby mode table" and is
used internally by the NTVDM on startup to do basic initialization.
So the TSR tries to determine the correct segment by reading INT 16h
handler assuming that it still points to the correct segment of NTDOS.SYS.
That's why it is important to place it very early in AUTOEXEC.NT before
other TSRs are loaded that may hook INT 16h.
For more details, just have a look at the sourcecode, it is well documented
and should be self-explanatory.

For further information, just contact me.

You can download this patch also as unregistered User:
http://www.waldbauer.com/tmp/dl.php?download=fixtmode

NTVDM Helper to enable Fullscreen operation with WDDM display driver
 

#unhide (This post can be viewed by guests also)

What is it
----------
Short version:
A package that enables you to switch between Windowed and Fullscreen mode
in a console in Windows 7 like it used to be in Windows XP, even though you
are using a WDDM display driver.

Long version:
You may already know that ALT+Enter is a commonly used hotkey to switch
application between window mode and full-screen mode. For the cmd prompt,
the hotkey should work as expected on prior windows OS up to windows XP
and for example enters real text mode for DOS applications.
But for Windows Vista and Windows 7, cmd can't be switched to
full-screen mode, this is by design.
For further information see http://support.microsoft.com/kb/926657
There is a very interesting article explaining the rasons behind this:
https://colinxu.wordpress.com/2011/0...ssue-analysis/

Now it's also known and explained in the KB-Article, that you can get
back fullscreen with either a XPDM-driver for the Windows XP display driver
model or to switch back to the default VGA video driver, which still
supports the old driver model.
Now the problem with a XPDM Display driver for Windows 7 is that it doesn't
support video accelleration on Windows 7, i.e. Window movement or scrolling
through websites in your browser can be a bit stuttering which isn't a
nice user experience.
As expained in the document of my CONHOST-Patch, Windows 7 thankfully has
the ability to enable and disable an active Video driver on-the-fly. When
disabling the WDDM driver, you fall back to the dafault Standard VGA display
driver which supports fullscreen textmode.
I presented a method that uses the utility DEVCON to disable and re-enable
the WDDM diplay driver in a batch file.
While this method works, it is a bit annoying to use, as one would have
to create a startup batchfile for every application that should work with
fullscreen. Additionally the "Start as fullscreen" in the PIF file still
doesn't work and you don't have the ability to switch from a windowed session
to fullscreen on-the-fly, like it used to be in Windows XP.
Additionally you need administrative rights to get the fullscreen switching
to occur. Running as Administrator gives you another environment than running
as user. And finally, you may also want your Win32 console in fullscreen,
not only DOS-applications.

So I had the idea to automate these tasks when either pressing ALT+ENTER or
when a console window wants so switch to fullscreen mode.

How it works
------------
The package is divided into multiple components:

* fullscrswitch service (with .dll file for eventlog messages)
* conhostfldr loader process, which is used in each session to
inject the conhostf.dll into the CONHOST.EXE process
* The conhostd.dll library which operates inside CONHOST.EXE
process to patch it accordingly for fullscreen operation
and communicate with the service.

First of all, disabling the WDDM driver is a privileged operation, so
administrative privileges are necessary for this.
Therefore it made sense to move this functionality to a Windows-service
which runs in the privileged context of the SYSTEM-user.
The service exposes its driver disable/enable services via a service
control code and also via a named pipe (.\pipe\fullscrswitch).
It is desirable that the WDDM driver stays disabled after switching
around between desktop and fullscreen console until all console windows
that use Fullscreen have closed. When all windows get closed (i.e. due
to an exit of the DOS application or the user just closing the
console window), the driver switches back to the accellerated
WDDM graphics mode.
So as long as you use Textmode fullscreen actively, you are limited to
the XPDM VGA driver and as soon as you do not need it anymore, you get
back your accelerated WDDM driver.
Due to the architecture of the new Windows console, every console has
a CONHOST.EXE process attached to it.
So the fullscreen service has to inject some loader code into every new
CONHOST.EXE process in order to capture ALT+RETURN keypresses or fullscreen
switch requests, then register the CONHOST.EXE process PID with the
fullscreen switching service and perform the WDDM driver disable task.
This is done by sending the PID of the CONHOST.EXE process to the named
pipe. The service registers the PID of the CONHOST in an internal list and
then waits on the process handle, until it gets signalled, which is the
case when the process terminates. As soon as all processes that registered
with the fullscreen switching service terminated, it is safe to switch
back to the WDDM driver, as there are no more processes depending
fullscreen operation.
The service writes back a BOOL TRUE on the named pipe to the caller in
order to signal that disabling driver succeeded and it can continue its
operation with fullscreen capabilities available now.

Now there needs to be a way to inject the conhostf.dll library into each
CONHOST.EXE process so that it can communicate with the service when needed
and modify its behaviour so that Fullscreen support gets available again.
For this, there is a nice facility in Windows: WinEvent hooks that get
called on various events, i.e. also console events. So you can get
notified when i.e. a new console application is starting. Additionally
you have the opportunity to get injected into the target process (to
do the patching), which is exactly what is needed.
Unfortunately there needs to be a "host" application that contains the
DLL to be injected which also needs to have a running message pump. This
is only possible in the context of the user that is currently connected
to the console.
As this is not possibe for a System service, a helper process is needed
which is called conhostfldr.exe that does the injection and acts as a
container for the loader DLL to be injected into CONHOST process.
This process needs high privileges in context of the user so that the
target DLL can also be injected into elevated console windows.
The service registers for logon/logoff notifications and therefore gets
notified when a user connects to the physical console. If the session
currently doesn't have the loader process running, it tries to start it
in the context of the user of the respective console session. It keeps
an internal list of the running instances and sessions.
When a user logs off or the service has to terminate, the loader process
for the sessions need to be terminated and the hook DLL needs to get
unregistered. To do this, and also to prevent being launched twice within
a session, the loader creates an Event named "conhostfldr" and checks
for it in its main message loop. As soon as this event gets signalled, it
terminates.
As the events are unique per session, the service is able to find the
event in the \Sessions namespace for the respective session and can set
the event causing the loader process to terminate properly and unregister
the hook libraray from the console window.

The injected library needs to adjust some internal functions of CONHOST.
As symbols and locations for these functions are not public, it is using
Microsoft Symbol Server to resolve them by name.
Symbol Server keeps debug information for every version of Microsoft
libraries and can download the appropriate symbol file via the Internet
(there are plenty of CONHOST.EXE releases for Windows 7 with different
offsets each, therefore this seems to be the only viable solution).
One problem is that conhost.exe checks for a fullscreen capable VGA
display driver during startup in internal function InitializeFullScreen().
Now if you start up a console with WDDM driver enabled the appropriate
values are no initalized. When you start a DOS application in console,
the NTVDM registers itself with a call to RegisterConsoleVDM() also
supplying event handles to events that are needed during Fullscreen
negotiation. Unfortunately the conhost.exe server part of this function
ignores these handles if the fullscreen flag (0x10000000) is not set
in gConsoleInformation.Flags. This flag normally gets set after
successful fullscreen initialization in InitializeFullScreen() function.
Now if you fake fullscreen initiaization, RegisterConsoleVDM saves the
handles, but it also requests the size of the state buffer from the
VGA driver with a call to GDI function
GdiFullscreenControl(FullscreenControlRegisterVdm, ...).
As at this time there is no VGA driver available, the function then fails
preventing a startup of the DOS application.
Fortunately, the value it requests there is always static for VGA cards,
so the loader DLL can simply hook the GdiFullscreenControl function and
fake the return value. Then the loader can pretend that fullscreen is
available during console startup by setting above mentioned flag.
If the user then really requests fullscreen operation, InitializeFullScreen()
can be called after disabling the WDDM driver as at this point the function
will then succeed ensuring correct operation.
The hook DLL has to monitor SrvSetConsoleDisplayMode call to check for
CONSOLE_FULLSCREEN_MODE call and the console window procedure to check
for ALT+RETURN keypress and then disable WDDM driver accordingly.

With all these 3 components in place, fullscreen switching should work.
Of course, it's not as fast as on Windows XP, because there is overhead
for disabling the driver, so if you can, using Windows XP is still the
preferred method, but with this patch you can at least partly restore
some of the lost functionality.

Prerequestites
--------------
All patches can be downloaded at http://www.waldbauer.com/tmp/reference.php

* CONHOST patch
The CONHOST.EXE on Windows 7 has a severe bug that causes it to hang
on switching back from Fullscreen mode to desktop. This patch fixes it.
* NTVDM transition timeout patch
There is a very large timeout of 5 seconds when switching back from
fullscreen to windowed mode. This is annoying, so with this patch you
can reduce this waiting time that occurs with some DOS applications.


Conditional prerequesites
-------------------------
If you have an Intel I3 or newer onboard graphics adapter and you
experience a startup delay from 5-10 seconds while starting a
DOS-application, there may be problem with the BIOS of the Intel
graphics adapter and you may need the
* NTVDM (Intel VGA BIOS patch)

If the video BIOS crashes on fullscreen or on mode switch, it is very
likely that the standard VGA driver doesn't know about the ports that
your video BIOS needs to route through to the NTVDM.
This is recommended for example for NVIDIA cards.
In this case, you can try this driver:
* http://www.rayer.g6.cz/download/videoprt.zip

If the driver above doesn't help or work and you have problems on
video mode switch of text modes, you can try this patch:
* NTVDM (NVIDIA GEFORCE VGA BIOS patch)

Recommended patches to enhance your DOS experience
--------------------------------------------------
Is Windows 7 doesn't work correctly with the PC speaker and instead
outputs BEEPS via the sine wave usermode beep agent, get back the
real PC speaker support with the
* BEEPx (SPKRFIX 32 bit)

The AltGR-Key is not handled correctly in NTVDM on Windows Vista or
above, so you need to install the
* ALTGR IAT FILTER HOOK

Then you can use the normal KB16.COM keyboard driver which you can
add to your AUTOEXEC.NT file in the SYSTEM32 Windows directory.

System Requirements
-------------------
Should work on any Windows 7 32bit machine.
It is advisable to have a running Internet connection on the first launch
of a console window on the patched system to enable symbol server fetching
the symbols required for proper operation of the patch. As soon as the
symbols got fetched, you don't need Internet connection anymore unless
you update your CONHOST.EXE process, i.e. by Windows update, in which
case the patcher will try to fetch the symbols again automatically.

How to Install
--------------
The installation doesn't work from a Network path, you need to run it from
a local directory. You need administrtive privileges to install.

1) Right-click on the conhostf.inf file in the bin\fullscrswitch
subdirectory and choose "Install".

If it works correctly, some files would have been copied and a
new service named fullscrswitch is started.

2) This step is not absolutely necessary and has the drawback of using more
diskspace than necessary, so this is optional:
Normally the loader tries to fetch the CONHOST.EXE symbols that it needs
for operation from Microsoft Symbol Server on first run, but lately the
symbols server sometimes is a bit unstable and fails to deliver the files
just in time. So you can optionally install all the conhost.exe symbols
that I know (which may not match your conhost.exe, but you can give
it a try anyway).
In case you want to install all the symbol files, just run opt\install.bat
and check if it copied the files successfully.

Now you can try to open a new console and see if ALT+RETURN works for
switching to fullscreen.
If the console hangs some time on first start, it tries to fetch the
symbols from symbol server. If it fails, it gives up after some time and
you get your console, but ALT+RETURN is not working. So as long as there
is some freeze on opening a new console, it tries to fetch the symbols and
you should try opening a new console (after freeze times out) as long as
this delay is still there.
If it doesn't work afterwards (even though it opens up fast), try to reboot
the machine once so that it gets ensured that the conhostdfldr.exe process
gets started correctly by the fullscrswitch service (you can check with
task manager).

If everything works fine, you should also be able to start your DOS
applications directly in fullscreen again.
However be aware that there are some conditions where it may hang your
graphics card (also depends a bit on your WDDM driver and how stable it is).
For example do not try to launch a DOS application fullscreen that
immediately exits, because the fast switching of the VGA driver may cause
a lockup. So when experimenting with it, be prepared that you may need to
reboot your machine if something goes wrong.

There also is a nasty issue with some Intel Onboard video drivers that
causes the disabling of the driver (to enable VGA) to block for approx.
10 seconds every second time you try, as it seems. I haven't analyzed this bug
in the Intel video driver yet as it seems to occur only with this cheap
onboard stuff (where you also need the Intel video fix patch from above).
So if possible better use a dedicated card.
As debugging kernel drivers is not so easy I don't know it if it's worth the
hassle, using a dedicated Graphics card is better anyway.
If this is really the only adapter you can use, maybe we can find a fix for
it together with Intel, just contact me.

When you use it and it switches to VGA mode, you may be set back to
640x480 resolution when you go back to the desktop, which is quite unpleasant.
Just use properties of display and switch to the maximum available resolution
that works with your monitor and VGA driver supports (i.e. if possible the
same resolution as with your normal video adapter driver) to get back normal
screen resolution in this mode. Windows will remember the settings on next
mode switch.

How to Uninstall
----------------
Go to control panel, Add/Remove programs and remove "Console Fullscreen
Patch".

Alternatively, you can run the following command on elevated command
prompt:

For further information, just contact me.

Hi

I have a problem that is somewhat similar in that I also have a computer with Intel integrated graphic. It's a Zotac ZBOX with Intel Celeron N3050 and Intel Graphics with PCI Id 8086:22B1.
I can confirm that text output in real mode during booting is really slow, although that is not the problem.

I did a fresh install of Windows 7. When I start any program that needs DOS mode, NTVDM starts and uses 100% of one CPU core. It happens with every program, like command.com. This is not just a 10 second delay, I waited for more that 45 minutes and nothing happens. This happens in window mode and even with remote desktop. When I try to switch to fullscreen, I get the message that fullscreen is not supported by the system. It also happened before and after I installed the driver for the Intel graphics.

I tried the utilities from this thread, but without success. conhost_pat says "cannot open file for writing", but Process Monitor doesn't show that it tries to open any file. The others seem fine but don't change anything.

Do you have and additional hints what I can try?

Hi,

Conhost outputs this error if it cannot open the file. Did you ensure that you closed all console windows before patching and also eliminated every running conhost.exe process in the system before patching?

If your BIOS has a flaw, you will need to debug it like I described in my VGA BIOS patch. Step through the assembly code and see where it loops. Maybe you can identify the flaw.
Theoretically if could be possible that it is related to the requirement of 32bit I/O which NTVDM isn't normally capable of. You would also see this in the debugger (look for IN/OUT on 32bit registers like EAX, EBX....).
If this is the case, I can provide you a patch that enables 32bit I/O in NTVDM.

I can't do analysis here, as I don't have a machine with this flaw to debug.
I could take a quick look at your machine i.e. via Teamviewer, if I can find something, I MAY be able to do a raw cost estimation after having a look at it for approx. one hour, if I find a hint. As I don't have such a machine here, you can either send me a machine with this hardware and I send it back after checking it, or you will have to provide access to the machine while I work on it, which means that you may not be able to use it for a few evenings.

That's all I can offer you so far.