VPCAppSv.sys blue screens XP Guest on XP Host

I am (trying to) use Embedded Visual C++ 4.0 on Parallels for Windows. The host is a Pentium XP SP2 machine, the guest is XP SP2 as well.

When EVC4 tries to access the WInCE emulator (VPCAppSv.sys is a part of this), the guest blue screens with a page fault.

VPCAppSv.sys is officially known by Microsoft to cause problems with XP SP2 "running in PAE or NX mode". Because of that, XP SP2 disables VPCAppSv.sys in that case. But that's apparently not what is happening, as VPCAppSv.sys IS enabled and crashes when used.

VPCAppSv.sys is obviously weird low level stuff, and it's doing emulation tricks itself, so I'm not too astonished (but unhappy) that it fails within a VM.

My first guess is that Parallels runs the guest in some mode that causes similar problems to VPCAppSv.sys as PAE or NX do, but such that XP SP2 does not detect it as such and therefore does not disable it.

At this time I'm testing with Parallels Win only because my Intel Mac is not yet here - as soon as it is I'll switch to Parallels Mac (already purchased). However now I'm a bit worried that I'll have the same problem with VPCAppSv.sys in Parallels Mac. I hope it'll behave different, as not having EVC4 emulated would be a show stopper for my virtualisation plans.

Any more info on this or experience running the WinCE emulator on Parallels?

 

Try to set normal acceleration mode in VM configuration in Options->VM flags tab. It will slow down your guest OS but may solve BSOD problem.

 

I tried that. Indeed, now it does not blue screen the entire XP guest any more, but just crashes the application with an AV.

I'm now trying the same with "none" acceleration. However I'm not sure if I'll be still awake when XP finishes booting Seems to take ages .

Is there any in-depth information what this acceleration setting actually changes in terms of compatibility? It's an obvious guess that high acceleration uses some shortcuts that trade compatibility with real hardware (which is relevant in exotic situations only) for speed.

And is Parallels running under VT-x different in that regard? I mean, is the guest environment more compatible with real hardware with VT-x than without?

 

Addendum: I tried with acceleration=none. It took about 3 hours to boot XP and get EVC run and compile up to the point of failure, but it behaves as with acceleration=normal (crashes app with AV).

 

Thanks for reporting - we will investigate this.

 

Works better on Mac (with VT-x), but...

In the meantime, I got my MBP 17" (which is an insanely great machine btw.) and installed Parallels Mac Beta 6 (which is insanely great software).

The good news: VPCAppSv.sys does not cause any crash any more at this point.

The bad news: A bit later, when eVC4 tries to connect to the WinCE PocketPC emu (which started, but with a blank screen) the guest in VM hangs completely and causes 100% host CPU load.

Parallels' Mac GUI is still responsive, so I tried to pause (works) and suspend (works) and then resume (causes a fatal error with report, I sent it to support@parallels.com).

So it seems that VT-x makes this more compatible, but still not enough. Eventually, VPCAppSv.sys just does something weird that performs some orders of magnitudes slower than on a real PC. As I was on batteries, I couldn't let it run very long - but when I get a chance I'll try that to see if it eventually comes to life again after a few hours...

 

Hi

This has been a known problem on systems such as VMware for sometime. It appears to be 2 issues:


1. The emulator is based on Virtual PC, so you are running virtualization inside another virtual system. I have tried this before and as expected performance is terrible.

2. Apparently it programs APIC timer to issue interrupts at about 1MHz for some time. On real hardware it takes about 1 second until it gets through this phase, while in VM it takes day or two. (From an engineer on a rival product!)

Dave

 

Thanks, Dave for the information!

I'm not sure why I should expect this generally - after all, there's no CPU emulation involved, and on Parallels Mac the processor is almost real with VT-x.

Ok, this now explains everything. And, I guess, this is a complete show stopper for using WinCE emulators on Parallels

Any idea why they do such a strange thing with the APIC timer?

BTW: I also use PalmSim (similar concept, runs PalmOS in a x86 compiled form in some virtualized environment) - works fine.

 

Well virtualizing the CPU is only part of what goes on under the hood in these systems. VT-x and SVM alleviate some of the pain but not all. VT-d might help boost performance when it allows more hardware to be virtualized.

As for why it sets the APIC to that value is beyond me!

A bit more research shows that the version used in the emulator is from Connectix Virtual PC before MS acquired them. The VPSAppSv.sys driver from MS Virtual PC is supposed to work better on XP systems with PAE and NX support. As an experiment, and don't blame me if it goes wrong , try getting the MS VPC driver and replacing the WINCE one with it.

Dave

 

Excellent Idea! Thanks! Of course I tried immediately...

But the latest version I found of VPCAppSv.sys it that in VPC 2004, which is exactly the same as in the PocketPC emulators for eVC4. I also examined Virtual Server 2005, but there is no VPCAppSv.sys any more.

Unless there is a VPCAppSv.sys newer than "2.0 (Build 327)", it looks like not much hope

But thanks anyway!

 

Pity. I will have a look around over the weekend and see if I can find anything.