Support for Windows 10 desktop applications on ARM - MFC and COM and OPOS work? - winapi

I am trying to understand the barriers to porting a C++ MFC application that runs on x86 Windows 10 to an ARM Windows 10 device with the Qualcomm Snapdragon processor.
The 32 bit application has the following characteristics:
MFC with C++ used for the user interface
C used for the business logic
the source code is divided into about 30 different projects, some static libraries, some DLLs, some EXE
relies on Windows API for multi-threading, semaphores, mutexes, cryptology
uses COM objects from Third Party providers, OPOS Service Objects and OPOS Control objects
relies on local instance of SQL Server Express using ADO for database
This application compiles fine with Visual Studio 2015/2017/2019 targeting x86 and Windows 10.
My question is: what are the possible barriers to migrating this application to ARM Windows 10 using the Snapdragon processor?
A secondary question is what would be an appropriate, low cost ARM Windows 10 device? Most Windows 10 ARM Snapdragon devices from HP, Samsung, and Lenovo seem to be in the US$800 and up pricing and I'd like something more inexpensive as in less than US$200.
A side question: will the Snapdragon 410 processor work for initial testing and compatibility checks. I'm looking at the DragonBoard 410C from Arrow as a low cost test platform. https://www.arrow.com/en/products/dragonboard410c/arrow-development-tools
This DragonBoard™ 410C based on 96Boards™ specification features the
Qualcomm® Snapdragon™ 410 processor, a Quad-core ARM® Cortex™ A53 at
up to 1.2GHz clock speed per core, capable of 32-bit and 64-bit
operation.96Boards is a 32-bit and 64-bit ARM® Open Platform hosted by
Linaro™ with the intension to serve the software/ maker and embedded
OEM communities. DragonBoard 410C supports Android 5.1, Linux based on
Debian and Win10 IoT Core advanced processing power, WLAN, Bluetooth,
and GPS, all packed into a board the size of a credit card. It is
designed to support feature-rich functionality, including multimedia,
with the Qualcomm® Adreno™ 306 GPU, integrated ISP with up to 13 MP
camera support, and 1080p HD video playback and capture with H.264
(AVC).
The DragonBoard 820C may be a more appropriate test hardware as it is closer to what most Windows 10 ARM Snapdragon product offerings are shipping with. https://www.arrow.com/en/products/dragonboard820c/arrow-development-tools
What I have been able to find thus far
This posted question, Win32 support on Windows 10 , seems to be the closest to my question however there is no real answer. The accepted answer says "There's no x86 Win32 emulation at all. You need to use a toolset designed for the platform." which appears to be wrong according to the following articles:
https://www.techradar.com/news/windows-10-on-arm-is-set-to-become-more-useful-with-emulation-for-traditional-64-bit-apps
Right now, with Windows 10 on ARM laptops, it’s possible to run 32-bit
x86 desktop software using emulation, but not dedicated 64-bit
software like, say, Adobe’s Premiere Pro video editing app for
example.
https://channel9.msdn.com/Events/Build/2017/P4171 is a video that mentions x86 emulation
https://learn.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-x86-emulation discusses x86 emulation
Emulation for x86 apps makes the rich ecosystem of Win32 apps
available on ARM. This provides the user the magical experience of
running an existing x86 win32 app without any modifications to the
app. The app doesn’t even know that it is running on a Windows on ARM
PC, unless it calls specific APIs (IsWoW64Process2)
https://www.howtogeek.com/309119/what-is-windows-10-on-arm-and-how-is-it-different-from-windows-rt/
Windows 10 on ARM is completely different [from Windows/RT]. This is the full Windows
desktop experience. Microsoft has created a special emulator layer
that allows traditional 32-bit desktop applications to run on ARM
processors, so everything should “just work”. Microsoft even showed
off a version of Windows 10 Professional on ARM, and said it supports
all the usual advanced features you’d find on Windows 10 Professional.
The emulation works completely transparently to both users and the
programs they run. It uses the same WOW (Windows on Windows)
technology that Windows uses to run 32-bit applications on 64-bit
versions of Windows today. However, the x86-to-ARM emulation happens
entirely in software.
Compiling for ARM with VS 2017 and software component considerations
This article, https://pete.akeo.ie/2017/05/compiling-desktop-arm-applications-with.html , provides some details about compiling desktop applications for ARM using Visual Studio 2017.
This article, https://support.microsoft.com/en-us/help/4521606/windows-10-arm-based-pc , under the section about limitations mentions:
Drivers for hardware, games and apps will only work if they're
designed for a Windows 10 ARM-based PC. For more info, check with the
hardware manufacturer or the organization that developed the driver.
Drivers are software programs that communicate with hardware
devices—they're commonly used for antivirus and antimalware software,
printing or PDF software, assistive technologies, CD and DVD
utilities, and virtualization software.
If a driver doesn’t work, the app or hardware that relies on it won’t
work either (at least not fully). Peripherals and devices only work if
the drivers they depend on are built into Windows 10, or if the
hardware developer has released ARM64 drivers for the device.
The article also says in the same section:
64-bit (x64) apps won’t work. You'll need 64-bit (ARM64) apps, 32-bit
(ARM32) apps, or 32-bit (x86) apps. You can usually find 32-bit (x86)
versions of apps, but some app developers only offer 64-bit (x64)
apps.
Here is a Microsoft portal to Windows 10 on ARM documentation, https://learn.microsoft.com/en-us/windows/arm/ with links to various resources on the page as well as a left hand sidebar with additional documentation links.
Some considerations and additional information
Can SQL Server Express (or any version) run on RPi? and the answer appears to be there is no ARM version of SQL Express. However there is a comment that says there is an ARM version of SQL Server Compact. SQL Server Compact has been replaced by SQL Server localDB however I'm not sure if there is an ARM version of that or not however it seems to use parts of SQL Server so an ARM version seems doubtful. See https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/sql-server-express-localdb?view=sql-server-ver15
On the other hand it looks like Microsoft is releasing Azure SQL Edge which does run on x64 and ARM64. https://azure.microsoft.com/en-us/services/sql-edge/
This Developer Minute video from Microsoft describes the steps to enable ARM64 builds in Visual Studio. https://www.youtube.com/watch?v=OZtVBDeVqCE&feature=youtu.be and there are also instructions at this link https://blogs.windows.com/windowsdeveloper/2018/11/15/official-support-for-windows-10-on-arm-development/

One barrier that I am potentially having to face is the fact that I package/distribute my software (which is MFC-based) using the "Visual Studio Installer Projects" extension to build ".msi" installer files.
The trouble is that the extension does not (yet) include an option to target ARM64 systems, so I would have to recommend using the x86 version.
However, I have not yet been able to test whether or not this works. Does that MSI file install the software in the correct locations? (That is, the relevant "Emulation" equivalent of the "Program Files (x86)" folder.)
There is also the issue about which VC-RunTime Redistributable Package(s) should be installed: x86 or ARM64, or both?
I can, of course, build and package my binaries targeted to ARM64, but then there would be no way to let the MSI file properly install that to the 'native' "Program Files" location.

This post covers three related activities:
creating a low cost Windows for ARM device using the Raspberry Pi 4
testing a simple MFC application with Windows 10 ARM on that hardware
testing creating a Windows installer using Nullsoft Scriptable Install System (NSIS)
This post will be updated with additional information once I have done further tests with a larger and more complex MFC application.
pull the source and recompile the OPOS Control objects for ARM64
test with an ADO database engine interface
use semaphores, critical regions, and multiple threads
Note: since in my testing I'm using a preview version of Windows 10 ARM that is not supported by Microsoft on a device that is not supported by Microsoft or other vendor, there may be some difference between my experience and using actual Microsoft products.
The problem is that currently Windows 10 ARM is not sold as a separate product as is Windows 10 for Intel. It is an OEM product only. The only way I've found to use Windows 10 ARM on a cheap device for testing is this approach with a preview build of Windows 10 ARM.
Hardware setup with Windows ARM on Raspberry Pi 4
Looking at the prices for a Windows on Arm device, what I found was mostly in the US$500 and up range. I did find an announcement of a low cost development platform that Microsoft and Qualcomm were doing, the Snapdragon Developer Kit, however I was unable to find where that was available.
Availability of the Snapdragon Development Kit for Windows ARM
So I moved forward with Windows 10 ARM on a Raspberry Pi 4 B with 4GB of RAM and a 128 GB SSD using a USB 3.0 to SATA enclosure for my boot device.
I ordered a CanaKit from Amazon that contained everything I needed including case, power supply, Raspberry Pi 4 B with 4GB of memory, and a microSD card with Raspbian. I picked the 4GB version as that was enough memory for Windows 10 ARM and I wanted to limit costs.
I assembled the Raspberry Pi 4 and case with fan and heat sinks, inserted the microSD card, and powered up the Raspberry Pi. It booted from the microSD card and allowed me to install Raspbian with NOOBS. NOOBS seems to be improved since the last time I used a Raspberry Pi 3 B a couple of years ago. WiFi worked and I was able to update Raspbian.
For the storage with Windows 10 ARM, I used an older 128GB SSD I had lying around in a USB 3.0 SATA to USB enclosure. From what I've read, the difference between a microSD card and an SSD over USB 3.0 is considerable.
I used the UUP dump website to download the necessary components and create the .iso file for a preview build of Windows 10 ARM. Then I used the WoR project tool to create a bootable SSD from the .iso file created by the UUP dump tool.
This procedure takes a while for the tools to do their job however what I found was that the tools were impressively user friendly and building the preview Windows 10 ARM .iso file was straightforward.
One word of warning: the documentation for these procedures seems to be something of a moving target and the tools are improving. For an overview of the procedure see the following:
https://raspberrytips.com/install-windows10-raspberry-pi/
https://www.windowslatest.com/2020/07/24/install-windows-10-on-raspberry-pi/
This Ars Technica article, New script makes it easy(ish) to put Windows 10 or 11 on a Raspberry Pi, mentions this argument concerning using the preview Windows 10 ARM components:
The script's creator argues that it violates no laws or Windows
licensing agreements since it downloads all its code directly from
Microsoft's servers and installs Windows in an unlicensed, deactivated
state, just as it would install on a regular x86 PC without a product
key. Microsoft only sells licenses of the ARM versions of Windows to
OEMs. WoR-flasher has officially been tested using the 32-bit version
of the Raspberry Pi OS (and that's what I used to create some install
media, too), but it should run without issue on any Debian-based Linux
distributions.
While there is mention of having to update the Raspberry Pi 4 firmware to support a boot from USB, what I found was that the Raspberry Pi 4 I purchased Sept. 2021 already had the updated firmware. See Booting my Raspberry Pi 4 from a USB device
First, as I just said, USB boot is enabled by default on the Pi 4B
(and the Pi 400, by the way), but there is a small caveat to that. It
seems that some early bootloader firmware versions did not properly
support this, so you have to be sure that your Raspberry Pi 4 has
bootloader eeprom firmware dated Sep 3 2020 or later. There are two
ways to do this; either remove the microSD card and then boot, so you
can read the firmware date from the diagnostic screen, or simply run
vcgencmd bootloader_version. I have three Pi 4 units (with 1GB, 2GB
and 4GB of memory) which I got from the first batch available in
Switzerland, and all of them have Sep 3 firmware so I assume the older
firmware is not very common. If you happen to have an older version,
the instructions for updating are given in the USB mass storage boot
section of the Raspberry Pi Hardware Documentation.
The other requirement for USB boot is that you have to be booting
Raspberry Pi OS version 2020-08-20 or later. In practical terms this
simply means that you should use the latest Raspberry Pi OS image from
the downloads page (which currently is 2020-12-02), or if you are
going to copy an existing SD card check the contents of
/etc/rpi-issue. I am not going to get into a discussion of booting
other Linux distributions at this point, because I haven't had time to
try it out myself yet.
I shutdown Raspbian and powered off the Raspberry Pi. I removed the microSD card with Raspbian and plugged the USB 3.0 SSD enclosure into a USB 3.0 port and powered on the Raspberry Pi. Windows 10 ARM initialized and booted up.
I did have to do a couple of actions to allow the Windows 10 ARM installation to finish:
set region and keyboard
plug an Ethernet cable into the RJ-45 connector of the Raspberry Pi
use a personal Microsoft user account
Once completed I had a standard Windows 10 desktop with the Edge web browser. A simple check of task manager with Edge running showed I had about 1GB of memory available.
It appears that though Task Manager reports 4 GB of memory installed, Windows 10 ARM preview build on the Raspberry Pi 4 is using only 3 GB of that memory. I've seen mention of a BIOS change needed to enable the use of all of the 4 GB of memory.
Note: It looks like here is the BIOS change needed, Only 3 GB of RAM are available. How can I fix this?
keep pressing the ESC key after plugging in the power cord, until you see the UEFI setup screen.
go to Device Manager -> Raspberry Pi Configuration -> Advanced Configuration and change Limit RAM to 3 GB to Disabled.
press ESC several times to go back, then Y to save the settings when prompted and finally reboot the board.
Using Visual Studio 2019 for MFC on ARM
I decided to use Visual Studio 2019 Community Edition for my test MFC application.
I used Visual Studio to create an MFC project. I then tried to change to an ARM64 build which failed.
First of all I had to modify my Visual Studio 2019 installation to include the ARM MFC functionality. This required me to use the Visual Studio 2019 installer available in the Apps & Features panel of the Control Panel.
Press the Modify button and scroll down to near the bottom of the Individual components tab of the installer. Select the C++v14.29 MFC for v142 build tools (ARM) and C++v14.29 MFC for v142 build tools (ARM64).
During trying various things to get an ARM64 MFC build I ran into a problem with a linker error of MSB8041, see MSB8041: MFC Libraries are required for this project.
I did the Modify of the Visual Studio 2019 installation a couple of times and it finally seemed to work and I was able to do an ARM64 MFC compile of a generated MFC application source code body.
I transferred the MFC application .exe to the Raspberry Pi 4 and when I tried to run it, I received an error of the MFC .dll not being found.
I then modified the build Properties to use the MFC library as a static library, transferred the resulting MFC .exe file to the Raspberry Pi 4 and was then able to run it.
Note: I transferred a copy of the Visual Studio 2019 C++ Redistributable installer to the Raspberry Pi 4 and ran the installer. After doing so, the version of the test MFC application that used MFC as a .dll rather than as static library ran correctly. The name of the file is VC_redist.arm64.exe and can be downloaded from Microsoft from The latest supported Visual C++ downloads or it can be found in the installation directory for Visual Studio 2019. For Community Edition, the path to the folder is
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Redist\MSVC\v142.
Nullsoft Scriptable Install System (NSIS)
I have previously used the open source Windows Installer builder, NSIS or Nullsoft Scriptable Install System, for Windows 7 and Windows 10 on Intel so wanted to try the same software with Windows 10 ARM.
I thought that there may be some kind of script compiler switch or setting to create a Windows 10 ARM installer however reading the documentation and looking at the support forums it appears that there is no Windows 10 ARM target available when doing a build.
One of the threads in a support forum mentioned that while using an installer created by NSIS targeting Windows 10 ARM specifically was not available and probably would not be available, the Windows Installer created by NSIS should work on both Windows 10 Intel as well as Windows 10 ARM with the latest Microsoft changes to support x86 applications on Windows 10 ARM.
I created a simple NSIS script starting with an old one for a different, more complex x86 application for Windows. Instead of the standard path to the solution compile/link output folder, I used the path to ARM64 compile/line output folder.
I recompiled my MFC test application then compiled the NSIS script to create a Windows Installer. I transferred it to my Raspberry Pi 4 running a preview Windows 10 ARM build. I then ran the installer which completed successfully.
The MFC test program showed in the Start menu and I was able to run it by selecting the application from the Start menu.
I then uninstalled it using the Windows Control Panel and it uninstalled correctly.
The build components of this test was a single MFC application compiled using MFC as a .dll. There were only two files in the build: the .exe for the MFC application and a short text file to put into the same folder. I did not use the standard Windows application path for this test using instead C:\framework\saratoga which was created properly.
Additional notes and considerations
Windows 10 ARM preview build from UUP lacks MFC .dll
Based on my experience, the Windows 10 ARM preview build from UUP for the Raspberry Pi 4 lacks the MFC .dll. I don't know if the standard Windows 10 ARM build for the Snapdragon devices offered by various manufacturers such as Samsung and HP and Lenovo and Microsoft have the MFC .dll or not.
The workaround is to compile the MFC application with the static MFC libraries.
I looked to see if there was an ARM version of the MFC .dll with my Visual Studio 2019 installation on my workstation but was unable to find one. I did find a redistributable runtime installer for ARM so perhaps an MFC .dll is in there. I did not use the redistributable runtime installer so it appears that the standard Visual Studio 2019 C++ runtime is a part of Windows 10 ARM preview from UUP.
Note: After finding the Visual Studio 2019 C++ Redistributable for ARM and running it on the Windows 10 ARM installed on the Raspberry Pi 4, the MFC .dll is now available and the non-static linked version of the test application runs fine.
Windows 10 ARM preview build is test mode
The Windows 10 ARM preview build from UUP has a note on the desktop in the lower right hand corner that it is in "test mode" with an additional note that Windows needs to be activated.
I don't know whether that means that this Windows install will become unusable within a certain amount of time or not.
Nullsoft Scriptable Install System
Using NSIS to create a Windows application installer appears to create an installer that works for Windows on Intel as well as Windows 10 ARM.
From what I have been able to find, it appears that with the more recent enhancements to Windows 10 ARM and support of x86 applications, any Windows Installer creating program which uses an engine compiled for x86 (not a 64 bit application) can be used on either Windows 10 Intel or Windows 10 ARM.

Related

Emulator not opening in Visual Studio for Xamarin mobile app development

I am trying to develop a mobile app using Xamarin and Visual Studio 2019 on a Windows 8.1 Pro operating system. I installed the .NET desktop development, ASP.NET and web development, and Mobile development with .NET workloads, and I am trying to run the Pixel 2 Pie 9.0 - API 28 emulator in Visual Studio.
When I try to launch the emulator through the Android Device Manager, I get the following error:
Device error: WARNING: unexpected '-prop' value ('monodroid.avdname=pixel_2_pie_9_0_-_api_28'), only 'qemu.' properties are supported WARNING: unexpected '-prop' value ('emu.uuid=a7af4d97-19e3-499d-9c26-334ea3d7cfe0'), only 'qemu.' properties are supported
enter image description here
When I try to launch the emulator through the green triangle at the top of the Visual Studio user interface, I get the following performance warning:
Performance Warning: Launching the Android Emulator pixel 2 pie 90-api_28 on Hyper-V needs Windows Spring Creators Update (Redstone 4) or newer installed. Please update your system and retry.
enter image description here
My laptops
OS : Windows 8.1 pro
64-bit Operating System
Processor: Intel(R) Core(TM) i3-5005U CPU # 2.00GHz
RAM : 4.00 GB
enter image description here
I went through Android Device Manager and edited the emulator I had installed. There I changed its name and processor to x86_64 instead of x86 and downloaded it. Then I restarted the computer and ran the emulator. But there also the same double error message as mentioned earlier, no difference. My data is limited so I didn't waste it on more guesswork. But I will gladly accept any of your recommendations
I want to solve the above problems under this operating system. I am currently unable to upgrade my operating system to Windows 10 or 11. I want to work in Visual Studio with minimal error messages. Having to use another emulator or old technology is not a problem there.
What could be causing these errors, and how can I resolve them? Any help or suggestions would be greatly appreciated. Thank you in advance.
Although not directly related to this, I will mention the following issues.
When I installed the emulator in Visual Studio Xamarin I got a prompt to install intel HAXM. But its automatic installation failebd and I downloaded and installed it manually from Intel website there. After that I got the two errors in the screenshot above.
When doing that I had installed both the latest version of Visual Studio 2022 and this 2019 version. (I was able to install both in Windows 8.1 Pro) Then I uninstalled the 2022 version.
Also, even though I installed it under the update I received for version 16.11.25 of Visual Studio, over a day later, It's not updated in the Visual Studio installer or the versioned install in the IDE.
And in my Visual Studio installer, above the Modify button, under Total Space Required , 13MB of non-removable space is noted. I have run the Modify button several times but it won't go away. (That may have something to do with the note "System cache, tools, and SDKs with fixed locations - 13 MB" on the Installation locations tab in the installer.)
When opening ASP.NET and wed development and Mobile development with .NET (out of support) workloads for the first time, the nuget.org package source was not included in the package sources by default. So the packages got errors. I then solved the problem by adding the nuget.org package to the source.
You can check this Hardware acceleration for emulator performance (Hyper-V & HAXM) for more information.
In this article, you can see the minimum criterion of the Hyper-V.
Your computer hardware must meet the following requirements:
A 64-bit Intel or AMD Ryzen CPU with Second Level Address Translation
(SLAT).
CPU support for VM Monitor Mode Extension (VT-c on Intel CPUs).
Minimum of 4-GB memory.
Virtualization Technology (may have a different label depending on
motherboard manufacturer).
Hardware Enforced Data Execution Prevention.
Verify that the Windows Version is at least 1803
To verify that your computer hardware and software is compatible with Hyper-V, open a command prompt and type the following command: systeminfo.
I unticked Hyper-V through the control panel and restarted the computer, where the emulator opened without error messages. But it takes a long time

Cross-compiled exe slow on some windows machines

I have a library which is cross-compiled inside Ubuntu with MinGW 7, GCC 9.3.0 for Windows.
The purpose of the library is to provide a CAN protocol over PCANBasic (CAN driver for Windows).
I call these library functions inside a C# .Net Framework 4.6 WPF Application.
Everything works but on some Windows 10 machines, the program's CAN communication is extremely slow. But these machines do have more CPU power (quad core instead of dual-core or more GHz). All use the same PCAN USB driver library.
I am not a professional Windows developer nor a .Net Developer so I only have some unanswered questions.
Can there be missing OP-Code for the CPU?
Could there be something running in compatibility mode?
Can I somehow analyze the USB load like on Linux?
Sorry for the may broad question but I am a little bit lost what to do.

Does windows CE work on ARM processors?

I am a little confused. When I search the internet I see examples of Windows CE running on Raspberry Pi or Samsung ARM11. However, I cannot be sure if they hacked it somehow or CE officially runs on ARM devices.
If it does not, should I use Windows Embedded products to target arm processors?
And the last question is that How does Windows CE fare when compared to Windows Embedded 7 in terms of footprint?
Can anybody enlighten me please?
Yes, Windows CE (lately renamed Windows Embedded Compact) runs on ARM. Up to version 6 it supported also SH4 and in Compact 7 MIPS.
Latest version is named (confusingly) Windows Embedded Compact 2013 and Microsoft is committed to support it up to 2023.
It's a different kernel (real-time) but provides some compatibility at the API level with desktop and server versions.
The new Windows IoT Core version runs on Raspberry Pi 2 (ARMv7) and uses the same kernel of the PC version.
Microsoft used an ARM build of Windows CE for Windows Phone 7, 7.5, 7.8, before they jumped to running NT on their ARM phones. For sure it exists.
I can't figure out if you can actually get it though. They have "Windows Embedded Compact 7", but from the documentation, it sounds like it's only x86 and amd64. But maybe there's some way to get the ARM version... maybe an MSDN license or by being some kind of business partner with Microsoft?
On second thought, this link: http://www.microsoft.com/windowsembedded/en-us/windows-embedded-compact-7.aspx suggests that it does work for ARM.
Bonus: Apparently Windows 10 will run on the Raspberry Pi 2: http://arstechnica.com/information-technology/2015/02/windows-on-arm-lives-on-even-as-it-dies/ The only question is if they'll keep requiring every non-app .exe to be signed by Microsoft like they did with the surface RT, preventing normal win32 or .NET programs from being possible to develop for ARM on NT. If they don't give us that crazy restriction, this could be pretty neat.

How to simulate sensors with Visual Studio 2015 and Windows 10?

I'm trying to develop a simple Windows 10 app and I wanted to simulate a Pedometer for testing. How can I do that? And what about other type of sensors, can I simulate them too?
Ok I found a solution.
Microsoft provides sample drivers here and there you can find sensors folder. So download what you need, compile and deploy.
To compile you need Windows Driver Kit.
If you're deploying to a x64 machine the drivers has to be signed. I had trouble signing the drivers so I booted Windows 10 with no driver signature enforcement and deployed the driver using DevCon. Check the driver INF once compiled to see the installation instructions.

WP7 Emulator, Windows 8, Intel GPU driver

After I run my application on WP7 Simulator on Windows 8 x64, Intel GPU driver crashes, with the following in the system event log: "Display driver igfx stopped responding and has successfully recovered". It doesn't occur immediately after I launch my application, only a few seconds later. After Windows resets the GPU and recovers, the emulator screen stays black.
The GPU is Intel HD 3000 inside 2-nd generation mobile core i5 CPU.
On Windows 7 x64 everything works great, which rules out hardware problems.
I've tried both upgrade 7 -> 8, and clean install. I have WP SDK 7.1.1, Visual Studio 2010 SP1, Windows Market Place Client, XNA Game Studio 4.0 all installed.
How do I fix the emulator and/or Intel GPU driver and/or my app?
P.S. I have another GPU by nVidia. however nVidia has a predefined setting "Windows Phone 7 Emulator" , so I can't switch the graphic processor for the emulator, the option is set to "Integrated graphics" and grayed out. When I used some utility to overcome that defect in nVidia's drivers, XDE.exe started to crash upon launching, saying "0xC0000005: Access violation writing location 0x00000000".
have you checked for all: disk/file corruption, other major drivers, BIOS, low level chipset driversand even startup programs/services including antivirus/antispyware/security programs.
and get the latest drivers here Intel drivers

Resources