XP pro vs. 2000 pro in a data acquisition environment

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

Guest

We have several PCs running Windows XP Pro that have data acquisition
hardware installed. We've had most of these crash almost weekly, and a
co-worker decided to put Windows 2000 pro on one of them. For whatever reason
(hardware being the same) it appears that the Windows 2000 machine does not
crash as much if at all.
It makes me ask the question. Is 2000 more reliable than XP?
I will also be searching the forums so that this question isn't a dead
horse..
But I'm just wondering if there would be any reason for the results we see.

Regards,
Jeffrey Scharpf
 
Hi Jeff,

I would be curious to know if you could install your data acquistion
hardware back onto a Windows XP PC and then use compatibility mode to run the
software in Windows 2000 rather then Windows XP. Also, are you using XP SP2
or SP1? Did your hardware come with drivers that were compatible with XP?
 
jeffscharpf said:
We have several PCs running Windows XP Pro that have data acquisition
hardware installed. We've had most of these crash almost weekly, and a
co-worker decided to put Windows 2000 pro on one of them. For
whatever reason (hardware being the same) it appears that the Windows
2000 machine does not crash as much if at all.
Click to expand...
It makes me ask the question. Is 2000 more reliable than XP?
Click to expand...


No. They are both very stable and reliable, but if anything the opposite is
true: XP is even more reliable. Realize that under the hood Windows 2000 is
Windows NT 5.0 and XP is NT 5.1. Despite its different name, given for
marketing purposes, XP is just a newer improved version of 2000.

I will also be searching the forums so that this question isn't a dead
horse..
But I'm just wondering if there would be any reason for the results
we see.
Click to expand...


There's always a reason. It's difficult to be sure what it is, but since the
Windows 2000 installation is new and the XP installations are older, all
kinds of things could have gone wrong with the XP installations--viruses,
spyware, and lots of other choices.

If you want to pursue this here further, please provide details of the
crashes you get, including the exact verbatim text of any error messages.
 
jeffscharpf said:
We have several PCs running Windows XP Pro that have data acquisition
hardware installed. We've had most of these crash almost weekly, and a
co-worker decided to put Windows 2000 pro on one of them. For whatever
reason
(hardware being the same) it appears that the Windows 2000 machine does
not
crash as much if at all.
It makes me ask the question. Is 2000 more reliable than XP?
I will also be searching the forums so that this question isn't a dead
horse..
But I'm just wondering if there would be any reason for the results we
see.

Regards,
Jeffrey Scharpf
Click to expand...


My experience with data acquisition cards and other specialized PC cards
(e.g. synchronous serial cards) leads me to believe the problems are
probably more hardware related.

Do both computers implement PCI IRQ sharing? Or are were talking about
PCMCIA cards? If PCMCIA, are both machines running the same cardbus
drivers? If PCI, are both/neither machine running under a legacy PCI BIOS
configuration? Are the Resources (IRQ, address ranges, etc) listed under
Device Manager identical? Are both machines equal functionality and speed
on the PCI bus?

Any additional information could help get to the bottom of this.

carl
 
Thanks again for the replies.
I will try to clarify.
Some of the systems just go down and restart with no messages or any
indication that anything happened. All I see in the Event Viewer is when
windows started up. What seems to happen is it's as if someone pressed the
reset button.
Other times I would get a blue screen of death and a memory dump.
I downloaded some program (can't remember what it was called) that analyzed
the memory dump. When I ran this program, it appeared to point to the driver
that comes with the data acq. hardware. But a phone call to them lead nowhere
other than "dl the latest version".. which I did. In any event, they told me
that if I run some type of diagnostic software it could cause a crash because
they are reading into DMA.. so they did not believe my results..

I do not know about the IRQ sharing. I will guess and say that it is
whatever the default of the BIOS is. This data acq. card is the only thing
plugged in to any PCI slot, and if there's something in BIOS that I can
change, I will gladly try it.

I hope this helps for now.

I don't know how to attach a file so following is text from this diagnostic
software:
Symbol search path is:
SRV*c:\debugsymbols*http://msdl.microsoft.com/download/symbols
Symbol search path is:
SRV*c:\debugsymbols*http://msdl.microsoft.com/download/symbols

Loading Dump File [C:\WINNT\MEMORY.DMP]
Kernel Complete Dump File: Full address space is available

Symbol search path is:
SRV*c:\debugsymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 2000 Kernel Version 2195 (Service Pack 4) UP Free x86 compatible
Product: WinNt
Kernel base = 0x80400000 PsLoadedModuleList = 0x80480780
Debug session time: Wed Dec 22 12:34:57 2004
System Uptime: 0 days 0:40:07.734
Loading Kernel Symbols
........................................................................................................
Loading unloaded module list
..............
Loading User Symbols
..................................................................
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C4, {12, 8, 0, 81c1d000}

*** WARNING: Unable to verify timestamp for ntdll.dll
*** ERROR: Module load completed but symbols could not be loaded for ntdll.dll
*** ERROR: Module load completed but symbols could not be loaded for
cbulwdm.sys
Probably caused by : cbulwdm.sys ( cbulwdm+83b5 )

Followup: MachineOwner
---------

kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA
will
be among the most commonly seen crashes.
Parameter 1 = 0x1000 .. 0x1020 - deadlock verifier error codes.
Typically the code is 0x1001 (deadlock detected) and you can
issue a '!deadlock' KD command to get more information.
Arguments:
Arg1: 00000012, caller is trying to free nonpaged pool at an IRQL above
DISPATCH_LEVEL
Arg2: 00000008, current IRQL
Arg3: 00000000, pool type
Arg4: 81c1d000, pool address

Debugging Details:
------------------


BUGCHECK_STR: 0xc4_12

CURRENT_IRQL: 8

POOL_ADDRESS: 81c1d000 Nonpaged pool

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 8052bc08 to 80526380

STACK_TEXT:
ec1efbc8 8052bc08 81c1d000 a4dfef78 8052bbf1 nt!ExFreePoolSanityChecks+0xbe
ec1efbd4 8052bbf1 81c1d000 00000000 ec0683b5 nt!VerifierFreePoolWithTag+0x14
ec1efbe0 ec0683b5 81c1d000 a5112e70 0f490900 nt!VerifierFreePool+0x1f
WARNING: Stack unwind information not available. Following frames may be
wrong.
ec1efbfc ec067703 a5112e19 ec1efc18 81ba0488 cbulwdm+0x83b5
00000001 00000000 00000000 00000000 00000000 cbulwdm+0x7703


FOLLOWUP_IP:
cbulwdm+83b5
ec0683b5 33c0 xor eax,eax

SYMBOL_STACK_INDEX: 3

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: cbulwdm+83b5

MODULE_NAME: cbulwdm

IMAGE_NAME: cbulwdm.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3c88eb2e

STACK_COMMAND: kb

BUCKET_ID: 0xc4_12_cbulwdm+83b5

Followup: MachineOwner
 
Back
Top