So what you are experiencing is a BSOD (blue screen of death), but it
is not staying put on the screen long enough to read. Your WinXP computer
is rebooting immediately. You can change that behavior, so the BSOD stays
on the screen long enough to copy down all the numbers. After you have copied
the numbers you can restart. Since you are crashing the system without a
clean shutdown, there is a good chance CHKDSK is going to run, to fix the
file system. (And if CHKDSK is not running, to be safe I'd probably run
it without a detailed check, just to be sure.)
Control Panels:System:Advanced:Startup and Recovery:untick Automatically restart
If you are lucky, there will be a driver name in the error message. It might
look like this for example. In this case "ati3d2ag" is an ATI video card driver
file name. See if you can post this info. The first numbers are likely to be
the most valuable ones, as well as any driver names or OS file names you can find.
Stop : 0X0000007E (0Xc0000005, 0Xxxxxxxxx, 0Xxxxxxxxx, 0X00000000) ati3d2ag.dll
BFA86515 base at BFA17000, date stamp 3f7a342b
You can read up on STOP errors here, in particular the section on "7E". With
some luck, there will be a Microsoft article link, which provides decoding of the
error fields in the brackets. And no, reading this is not going to even hint
about where the problem lies. You seldom get an instant answer, based on looking
at the error numbers.
http://aumha.org/a/stop.htm
The fact the device shows up as a digital camera, is also interesting. You'd think,
if a special driver was in place, the device would be recognized by its Plug and Play
information.
Normally, you can use a program like UVCView, to review the USB config space
data presented by the device. Then, extracting the VEN/DEV or VID/PID values,
match that to the driver used for your device, to learn more about how the
system is handling the new hardware when it makes its appearance.
Some devices use standard class codes, as well as the VID/PID. A digital camera,
for example, might use a USB Video Class (UVC) class code, saying it follows
a particular standard for digital cameras. The Microsoft OS, if no custom
driver package was installed, might then use the built-in UVC driver.
If the device was not actually UVC, then all hell might break loose.
Accurate Plug and Play information is important, to proper system function.
If a device is completely non-standard, then it might use an "empty"
class code of sorts, and that might help the OS eventually match the
device to its own custom driver. It would help if the custom driver
was installed in the OS, *before* the device is plugged in. Once a device
is plugged in, there can be a "memory" of what happened, stored in the
WinXP registry. A procedure for clearing the registry is described here,
for USB, while the computer is booted in Safe Mode (press F8 at startup).
http://www.usbman.com/Guides/Cleanup Device Manager Safe Mode.htm
But if the software provided by Apple is just stupid, you might experience
the same crash, the next time the device is plugged in. And even if you have
cleaned out all USB related stuff first.
Now, if the device did not crash the computer, we could get out UVCView and
start analyzing what the IPad is saying about itself. It could be USB Mass
Storage, MTP, a composite device with camera and audio, it could be quite
complex. But to use this, you are going to have to be successful at stopping
the system crash first, as otherwise, you will never get to run this with the
iPad plugged in.
*******
ftp://ftp.efo.ru/pub/ftdichip/Utilities/UVCView.x86.exe
http://www.users.on.net/~fzabkar/USB_IDs/UVCView.x86.exe
File size is 167,232 bytes.
MD5sum is 93244d84d79314898e62d21cecc4ca5e
This is a picture of what the UVCView info looks like.
http://www.die.de/blog/content/binary/usbview.png
Some information on the parameters seen in UVCView.
http://www.beyondlogic.org/usbnutshell/usb5.htm
You should be able to get VID/PID info from a plugged
in device. That program will also help you determine whether
the device is alive at all or not.
*******
An alternative way to start IPad analysis, would be to boot a Linux
LiveCD and use "lsusb" to get some info on the device. I do not see
a reason to go that far, just yet.
OK, while I was writing this, I was downloading the latest ITunes.
I have a WinXP 32 bit OS, which the Apple web site automatically
detected when I connected with my web browser. Using 7-ZIP, I took
a look inside the 74,840,872 byte download.
AppleApplicationSupport.msi
AppleMobileDeviceSupport.msi <---
AppleSoftwareUpdate.msi
Bonjour.msi
ITunes.msi
QuickTime.msi
SetupAdmin.exe
Inside AppleMobileDeviceSupport.msi , I can find AppleMobileDeviceSupport.cab .
And inside there, I can find "usbaapl.inf".
Now, if I go here, I can get the VID and PID values for iPad.
This is an informal registry of USB devices, used by the Linux
community.
http://www.linux-usb.org/usb.ids
05ac Apple, Inc.
129a iPad
The matching entry in usbaapl.inf is
; iPhone (Mobile Device)
%iPhone.DeviceDesc%=USBAAPL.Dev, USB\VID_05ac&PID_129a
I suspect the device is supported by this -
[USBAAPL.AddService]
DisplayName = %USBAAPL.SvcDesc%
ServiceType = 1 ; SERVICE_KERNEL_DRIVER
StartType = 3 ; SERVICE_DEMAND_START
ErrorControl = 1 ; SERVICE_ERROR_NORMAL
ServiceBinary = %10%\System32\Drivers\usbaapl.sys
LoadOrderGroup = Base
Perhaps someone else here, can suggest where you can verify this
is set up.
A log of an attempt to install the device, would normally be
recorded in C:\WINDOWS\setupapi.log and down near the end of that
file, you would look for VID_05ac&PID_129a . If WinXP "stayed up"
long enough to finish device recognition and installation, there
will be info in setupapi.log.
That's not an answer, but it is a starting point, on how
you start debugging.
Paul
