SP2 kernel causes device drivers to hard-lock

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I need some help guys. I'm struggling with a device driver that works
perfectly well in windows XPe SP1 and Windows XP *Pro* SP2. If i upgrade my
XPe project to service pack 2, interacting with the same device will
freeze/hard lock my system. There is no error message... the problem seems to
be low level.

I have narrowed the instability to the following 8 "changed" files in SP2. I
know this because if i copy these select files from the working SP1 build the
non-working SP2 image then _works normally_.

The files seem to be the XPe kernel: cdfview.dll, hal.dll, ntoskrnl.exe,
ole32.dll, shell32.dll, win32k.sys, user32.dll, winsrv.dll.

Any ideas why this device is unstable in XPe SP2, yet stable on XPpro SP2?
Is there really that much difference between the two kernels?
 
Hi Paul. Between SP1 and SP2, some registry information related to device
drivers got moved around, so installing an SP1 driver component on an SP2
runtime will most likely not work as it did in the SP1 runtime. These
differences mainly involve security-oriented information, but some driver
settings and such I don't have specifics on the nature of these changes, but
I can attempt to help you troubleshoot this problem.

1. Is this a device driver that Microsoft provided "out-of-box"? (A driver
exists in the SP2 component database for this device?) Or is this a
third-party driver that you or the vendor componentized for Embedded?

2. If this is an out-of-box driver, what is the name and type of device that
is causing the problem?

If this is a new or custom component designed for SP1, you may need to
re-componentize the driver for SP2. If you got this component from a third
party vendor, please check with the vendor to see if an updated component
exists.

For more information on componentizing third-party drivers, check out the
following article on MSDN:
http://msdn.microsoft.com/embedded/community/community/tips/xp/thrdprty/default.aspx .

I hope this helps. =)

--
Matt Kellner ([email protected])
STE, Windows Embedded Group

This posting is provided "AS IS" with no warranties, and confers no rights.
===============================
 
Hi Matt,

The driver is from a third-party vender for a rather complex ticket scanner
(imaging) device, which works for the most part until the imaging takes
place. I have already gone about componentizing their drivers after the SP2
upgrade of my build environment. (Incidentally the manual installation
process produces the same crash results.) Our var, who is in closer contact
with the driver developer tells me that the part where the system locks up is
during the "direct memory access" phase, where the image is passed through
parallel port LPT1 into memory. We've made a few attempts to contact the
developers directly but have yet to get much response in the last week. I’m
afraid it’s largely because we don't really know what to tell them, given
that it seems to be a disagreement with their driver and the new service pack
of XPe. Maybe your help is best in this respect. It’s understood that their
driver may not be designed for XPe but it's unexpected that it now doesn't
work seeing as it was fine in SP1. In the mean time I’ll attempt to look
closer at the security changes you mentioned, perhaps it just needs to be
tweaked.

Thanks,
Paul
 
Paul,

XPP SP2 == XPe SP2. XPe and XPP with same patches (Service Pack) use same binaries.
There are few components in TD that will bring slightly different kernel files (ACPI, non ACPI, UP, MP) so choose kernel that best
describe your machine so that your XPP and XPe use binary same kernel files.

Please test these drivers only on XPP SP2 (not on XPP SP1) so that you can have clear picture of what kernel files are working with
that driver.

Drivers have a very little or no requirements outside the kernel space so correct hal.dll and ntoskrnl should be enough for it to
work. (Perhaps few other drivers that this driver relly on). You can use dependency walker to see all files that are used by your
driver.

Also is it little strange that you use DMA on LPT port. What DMA channel and controler do you use? Check DMA assignement for some
possible conflicts/problems.

Regards,
Slobodan
 
Back
Top