Compatability with Windows Embedded Standard?

[M_P]

I would like to utilize BurnInTest on a Tablet PC running Windows Embedded Standard. Since Windows Embedded Standard is based on Windows 7, can I expect that BurnInTest will work with this OS too?

[David (PassMark)]

Windows Embedded (at least past releases that I looked briefly at) is not a really a single O/S. It is a bunch of modules that can be included or excluded to obtain a certain combination of foot print and functionality.

In this environment we can not be sure anything will work. You need to test it in your senerio.

What I can say is that we support Win7 and that other customers did get it to work on past versions of Windows Embedded, once they included enough modules.

[loganovich]

Older versions of Windows Embedded Standard, yes. Windows Embedded Standard 7 is almost exactly Windows 7 split up into features sets or packages. As far as our company is concerned, this is the first bit of software that we've tried on this system (after countless drivers and other applications) that does not work.

[David (PassMark)]

Windows Embedded Standard 7 is almost exactly Windows 7 split up into features sets or packages

Which sounds more or less the same as past Windows Embedded releases.

If it doesn't work then you must be missing some functions in Windows. BurnInTest was designed to exercise a lot of different parts of the system, so you might find you need to include a significant part of the Windows O/S before it works.

[loganovich]

Using the same image (Windows Embedded Standard 7, based on "application compatibility" template), we can run build 1011 of passmark burnin test without failure. On the other hand, running build 1028 results in BSODs.

Is there something that we can run or do to see what Burnin is failing with? It is possible that the root cause of this issue could be Windows Embedded Standard 7, but given the success we've had with everything else (and to be clear, EVERYTHING else), I'm hesitant to point a finger solely at WES7.

[Ian (PassMark)]

The problems in the past with using BurnInTest on Windows embedded have been mainly related to missing fonts (the look of the user interface) and a missing dll for Windows media playback (BurnInTest won't start). If build 1011 works and 1028 does not, then maybe it is not a WE7 issue.

What is the BSOD? What diagnostic information is on the BSOD and can you send us a system dump of the crash?

When does the BSOD occur (on starting BurnInTest, running a particular test etc)?

If the BSOD occurs when running tests, can you reduce the test set to find the minium test set that casues/provokes the BSOD?

Our email address is shown here:
http://www.passmark.com/support/index.htm

[loganovich]

Here's what is posted in the BSOD:

*** STOP: 0x0000008E (0xC0000005, 0x8DC01022, 0x8078AE74, 0x00000000)

*** intelppm.sys - Address 8DC01022 base at 8DC00000, DateStamp 4a5bb507

For the two issues you mentioned - missing DLLs and/or fonts - could you be more specific? Which fonts do we need to ensure are installed? Which DLL do we need for windows media?

[David (PassMark)]

I did a quick search on the net. Blue screens from the intelppm.sys driver are common (even without using our software).

One post suggested turning off this driver,
http://blogs.msdn.com/b/virtual_pc_guy/archive/2005/10/24/484461.aspx

Got to this registry location,
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Intelppm
And changing the 'Start' value to '4'.

There is a post here saying this Intel driver isn't compatible with Embedded.
http://forums.virtualbox.org/viewtopic.php?t=1560

[loganovich]

We've actually tried this already and it leaves the processors with a yellow bang on them in Device manager. This is an unacceptable state for us. We can follow up with Intel, but with the number of BSOD's that we've investigated in the past, the reported cause of the failure on the BSOD is not always the actual cause.

Again, is there anything that we can do to see if Passmark is doing something wrong? Some kind of logging for passmark?

Also, so that I'm clear - we've installed 40+ drivers and applications on this same system, connected over 30 different instruments into the system at the same time, and have run multiple tests that have all passed on this same image with Windows Embedded Standard 7. These same tests and same setup have been run with Windows 7 Professional, with the same result.

Finally, the post that you sent is in reference to Windows XP Embedded, which I cannot stress enough how different it is from Windows Embedded Standard 7. They have completely different kernels - therefore because something does not work in XPe is not sufficient rationale to say that it does not work in Windows Embedded Standard 7. Add to that the fact that the last post on that thread indicates that this is not an issue with Windows Embedded Standard 7, and we come back to Passmark Burnin Test, and what it is doing and what we can learn about what it is doing. Please advise.

[Ian (PassMark)]

Here's what is posted in the BSOD:
*** STOP: 0x0000008E (0xC0000005, 0x8DC01022, 0x8078AE74, 0x00000000)
*** intelppm.sys - Address 8DC01022 base at 8DC00000, DateStamp 4a5bb507

We had a report of this problem from an OEM. Intel analyzed the problem in their case and found that it was related to BurnInTest using a particular CPU register in the CPU detection on the statup of BurnInTest. The CPU detection mechanism for Sandy Bridge changed between 6.0.1011 and 6.0.1028.

Specifically, the problem was not with Intelppm.sys. Rather the problem was with reading the ACNT MSR (CPU register) when the ACNT2 feature is enabled on Sandy Bridge. A Microcode patch disabling the ACNT2 feature corrected the problem.

So if you are using a Sandy Bridge CPU I would check that you have the latest CPU microcode and that ACNT2 is disabled.

For the two issues you mentioned - missing DLLs and/or fonts - could you be more specific? Which fonts do we need to ensure are installed? Which DLL do we need for windows media?

msvfw32.dll (Microsoft Video for Windows).
Arial, MS Sans Serif and Tahoma are required (I think MS Sans Serif was missing).

[loganovich]

Thanks for this information. We've double checked and we have those fonts. We're double checking on the DLL.

I'll check for microcode updates, but we are not using Sandy Bridge where we are seeing this failure - not that the same failure won't show up; our testing to date has been on Intel's Arrandale processors.

We found this other thread that seems to be very similar to the issue that we are seeing:
http://www.passmark.com/forum/showthread.php?t=2499&page=2

I didn't see any notes in this thread as to what was actually changed in build 1023 to address this issue. Could you advise?

[Ian (PassMark)]

I believe these 2 problems, the one I mentioned in this post and the one in the post you referenced, are the same problem. Basically BurnInTest uses a CPU register to determine the CPU speed at atartup. As this register is specific to certain CPU's BurnInTest checks whether it is supported before it uses the register. In the case of the post you referenced, and I suspect in your case, the CPU indicates the register is supported, when it seems it is actually not supported.

As I mentioned, an OEM had this problem and this was corrected with a CPU microcode update.

In the case of the post you referenced, as a work around in BurnInTest v6.0.1023 we removed this CPU detection when running on WinPE.

What we have now done in a new build of BurnInTest is to provide an option that is a work around to the problem described above. BurnInTest has a command line parameter to minimize the amount of system information it collects on startup, "-W". From BurnInTest V6.0.1029.0002 if you specify the "-W" command line parameter, the CPU detection mechanism using the CPU registers is skipped.

Assuming you are using 32-bit BurnInTest Professional, please try the new build here with the command line parameter "-W":
http://www.passmark.com/ftp/bitpro6.0.1029.0002.exe