Firefox/4.0b8pre SeaMonkey/2.1b2pre   
   From: Lars Erdmann    
      
   Steven Levine wrote:   
   > On Mon, 25 Oct 2010 06:51:05 UTC, Lars Erdmann   
   > wrote:   
   >   
   > Hi Lars,   
   >   
   >>> I've seen the same (or a very similar trap on the 14.104a W4 kernel)   
   >>   
   >> Aha. Were you using ACPI back at the time ?   
   >   
   > No.  No ACPI and no APM .. This box does support hyperthreading, but   
   > I've never got around to testing it.   
   >   
   >> I am also using SNAP. What I indeed observe is that the WPS shortly comes up   
   >> and then, the system traps (with the trap E = PAGE FAULT).   
   >> So it could well be the GHI_CMD_INIT invocation of the GRADD driver   
   SDDGRADD.DLL.   
   >   
   > Possibly, but not according to what I see in the logs.  My analysis so   
   > far says, the loader is failing while trying to load   
   > \IBMLAN\NETPROG\NETGUI.PML for lsgwps.dll.   
   >   
   > This would be easier if the .pu# did not imply that the kernel stack   
   > was corrupted.  Does .pu# give sensible output wit your dump file?   
   > What I see here is   
   >   
   > # .pu#   
   >   Slot  Pid  Ord  pPTDA    Name     pstkframe  CS:EIP        SS:ESP   
   > cbargs   
   > *003a# 0026 0001 fa1584e0 PMSHELL  %f9cccf40 ffef:0000c511   
   > 0047:0008e948 000a   
      
   This is what I get:   
     Slot  Pid  Ord  pPTDA    Name     pstkframe  CS:EIP        SS:ESP     cbargs   
   *0045# 0026 0001 f95c1a78 PMSHELL  %f913af3c ffef:0000e3e1 003f:0007e978 000a   
   #   
      
   It therefore looks just as wrong. One observation: the same CS:EIP shows up   
   for a bunch of other   
   processes. It's in kernel routine UT32_TARGET and it's a jump from a 16-bit   
   code segment to a 32-bit code segment.   
   (the target of the jump is UT32_RETURN).   
      
   >   
   > which is basically gibberish.   
   >   
   >> the code and data segments fixed in memory. It is kind of undocumented what   
   memory you can touch when ...   
   >   
   > :-)   
   >   
   >> Ok, will give it a try. The problem is: the trap occurs rather seldom.   
   >> My gut feeling is, it occurs every now and then only when I reboot from my   
   WinXP partition   
   >   
   > It might be related to prior memory content.  This box is eCS/OS2 only   
   > and it still experiences the problem.  This sort of implies and   
   > uninitiailized variable or something like that.   
   >   
   >> into my OS/2 partition, I'll have to write a logbook ...   
   >   
   > I have this semi-automated.  Startup.cmd contains   
   >   
   >    echo Booted at %_DATE %_TIME>>  f:\%HOSTNAME-boot.Log   
   >   
   > and the startup folder contains an object that that opens epm for this   
   > file.   
   >   
   > Steven   
   >   
   >   
   >   
      
      
   --- Internet Rex 2.31   
    * Origin: Arcor (1:261/20.999)