<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: Bug in list management?
From: Damion Wilson <dwilson,AT,ibl,DOT,bm>
Date: Fri, 27 Apr 2001 16:35:14 +0200
In-reply-to: <B3F97C5A98D70F4EB72A31F79AEC6287026780@EXCHANGE.dmz.twobyfour.se>

I think that the problem with a disabled adapter is the same as the one
mentioned in the todo.txt as item "g". I will need to play with it a
little. I just know it's something weird.

Thanks again, you're really helping a lot. At this stage, some things are
difficult for me to debug because I'm too "close" to the code.

If you're trying to setup the DDK stuff, I can give you some tips if you
need them. It was a little weird for me when I started it. I mean, writing
drivers on Linux doesn't require any "special" software (!). Solaris has a
driver development kit, but it's just the includes and some libraries. This
Windows stuff, though, is really strange. The experience left me wondering
what kind of pine needles they smoke up there in Redmond...

Ah well, now I've either got to look for employment or set up a consulting
firm as I've officially been laid off.

DKW

On Thursday, April 26, 2001 at 18:05:52 [ADT] Erik Wallin wrote:
> I've tried it and things seem to be more stable. But, this is my home
> machine
> and for some reason it is more stable than the other machines I have
> tried it
> on. I managed to provoke a BSOD still by disabling the adapter while
> running
> traffic across the interafce. Here is the description:
> 
> Adapter enabled on boot.
> Start service after boot..
> Everything works fine. (Really! You're getting there!)
> Start copying a large file over the VPN tunnel.
> Disable adapter - BSOD
> 
> I'm being really nasty to the driver. For normal use it looks like it's
> working.
> 
> From the trace it seems like it's in the communication between the driver
> and
> the service. Maybe its the service trying to talk to a closed tap device.
> I'll
> se if I can understand that bit of the code. If this is the only bug
> left, I
> can live with it for a while.
> 
> Sorry about the lack of symbol info in the trace. I couldn't manage to
> compile
> cipe with symbols. I'll try again this weekend if I have time. I've still
> got
> some "hello world" difficulties. Could you include a symbol file in the
> distribution? That would make things easier and it would also ensure that
> we
> are testing the same binary. I might have a different version of the DDK
> or
> the compiler. The debugger shouldn't make much of a difference, but I'm
> running WinDbg 2.0.0023.0.
> 
> Pre9 is definitely a step forward.
> 
> I'll test more tomorrow. Now I'm of for some sleep. After all, tomorrow
> is
> friday, and in Sweden monday and tuesday are off. Great! Unfortunately
> the
> forecast is four days of rain, so I'll probably have time for some more
> testing. :-)
> 
> /Erik
> 
> Bugcheck code 00000050
> Arguments f25d8010 00000000 beba9380 00000000
> 
> ChildEBP RetAddr  Args to Child
> beb53b70 80465fc6 00000000 f25d8010 00000000 ntoskrnl!MmAccessFault+0x74e
> beb53b70 beba9380 00000000 f25d8010 00000000 ntoskrnl!KiTrap0E+0xc3
> *** ERROR: Module load completed but symbols could not be loaded for
> cipdrvr.sys
> beb53c34 8041f511 8247ed50 82664da8 82664da8 cipdrvr+0x1380
> beb53c44 800695bf 80498d61 82664e18 00000000 ntoskrnl!IopfCallDriver+0x35
> beb53c5c 804a1f3a 8247ed50 82664da8 82430de8
> hal!KeRaiseIrqlToSynchLevel+0xf
> beb53d38 80462cf1 00000088 00000084 00000000 ntoskrnl!NtWriteFile+0x67a
> beb53d38 77f83028 00000088 00000084 00000000
> ntoskrnl!KiSystemService+0xc4
> 004ffc4c 77e9cafd 00000088 00000084 00000000 ntdll!NtWriteFile+0xb
> *** ERROR: Module load completed but symbols could not be loaded for
> cipsrvr.exe
> 004ffcb8 00407382 00000088 0050fd30 0000059c KERNEL32!WriteFile+0xc5
> 004ffcdc 00408c4f 0050fd28 00000000 00000000 cipsrvr+0x7382
> 0050fd10 004085b6 0050fd28 00135918 00540232 cipsrvr+0x8c4f
> 0051fd44 0040232d 00000000 00135918 00135918 cipsrvr+0x85b6
> 0051fd90 004039c9 00000000 00135918 00135918 cipsrvr+0x232d
> 0051ffa4 77dc5ac5 00000001 00135920 0012f95c cipsrvr+0x39c9
> 0051ffb4 77e837cd 00135918 00000000 0012f95c
> ADVAPI32!ScSvcctrlThreadW+0xe
> 0051ffec 00000000 77dc5ab7 00135918 00000000
> KERNEL32!BaseThreadStart+0x52
> 
> eax=ffdff13c ebx=00000050 ecx=beb53b88 edx=8040069a esi=80069590
> edi=c03c9760
> eip=80447cc5 esp=beb53b30 ebp=beb53b70 iopl=0         nv up ei ng nz na
> po nc
> cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000            
> efl=00000286
> ntoskrnl!MmAccessFault+74e:
> 80447cc5 e9b5000000       jmp     ntoskrnl!MmAccessFault+0x74e (80447d7f)
> 
> 
> Damion Wilson wrote:
> 
> > I have embodied your suggestions and my fixes in CIPE-Win32-2.0-pre9,
> now
> > available on http://CIPE-Win32.sourceforge.net. I'm anxious to know if
> you
> > get the same uptime I do.
> >
> > Thanks, dude
> >
> > DKW
> 
> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
> I've tried it and things seem to be more stable. But, this is my home
> machine
> and for some reason it is more stable than the other machines I have
> tried
> it on. I managed to provoke a BSOD still by disabling the adapter while
> running traffic across the interafce. Here is the description:
> <p>Adapter enabled on boot.
> <br>Start service after boot.
> <br>Everything works fine. (Really! You're getting there!)
> <br>Start copying a large file over the VPN tunnel.
> <br>Disable adapter - BSOD
> <p>I'm being really nasty to the driver. For normal use it looks like
> it's
> working.
> <p>From the trace it seems like it's in the communication between the
> driver
> and the service. Maybe its the service trying to talk to a closed tap
> device.
> I'll se if I can understand that bit of the code. If this is the only bug
> left, I can live with it for a while.
> <p>Sorry about the lack of symbol info in the trace. I couldn't manage
> to compile cipe with symbols. I'll try again this weekend if I have time.
> I've still got some "hello world" difficulties. Could you include a
> symbol
> file in the distribution? That would make things easier and it would also
> ensure that we are testing the same binary. I might have a different
> version
> of the DDK or the compiler. The debugger shouldn't make much of a
> difference,
> but I'm running WinDbg 2.0.0023.0.
> <p>Pre9 is definitely a step forward.
> <p>I'll test more tomorrow. Now I'm of for some sleep. After all,
> tomorrow
> is friday, and in Sweden monday and tuesday are off. Great! Unfortunately
> the forecast is four days of rain, so I'll probably have time for some
> more testing. :-)
> <p>/Erik
> <p><tt>Bugcheck code 00000050</tt>
> <br><tt>Arguments f25d8010 00000000 beba9380 00000000</tt><tt></tt>
> <p><tt>ChildEBP RetAddr&nbsp; Args to Child</tt>
> <br><tt>beb53b70 80465fc6 00000000 f25d8010 00000000
> ntoskrnl!MmAccessFault+0x74e</tt>
> <br><tt>beb53b70 beba9380 00000000 f25d8010 00000000
> ntoskrnl!KiTrap0E+0xc3</tt>
> <br><tt>*** ERROR: Module load completed but symbols could not be loaded
> for cipdrvr.sys</tt>
> <br><tt>beb53c34 8041f511 8247ed50 82664da8 82664da8 cipdrvr+0x1380</tt>
> <br><tt>beb53c44 800695bf 80498d61 82664e18 00000000
> ntoskrnl!IopfCallDriver+0x35</tt>
> <br><tt>beb53c5c 804a1f3a 8247ed50 82664da8 82430de8
> hal!KeRaiseIrqlToSynchLevel+0xf</tt>
> <br><tt>beb53d38 80462cf1 00000088 00000084 00000000
> ntoskrnl!NtWriteFile+0x67a</tt>
> <br><tt>beb53d38 77f83028 00000088 00000084 00000000
> ntoskrnl!KiSystemService+0xc4</tt>
> <br><tt>004ffc4c 77e9cafd 00000088 00000084 00000000
> ntdll!NtWriteFile+0xb</tt>
> <br><tt>*** ERROR: Module load completed but symbols could not be loaded
> for cipsrvr.exe</tt>
> <br><tt>004ffcb8 00407382 00000088 0050fd30 0000059c
> KERNEL32!WriteFile+0xc5</tt>
> <br><tt>004ffcdc 00408c4f 0050fd28 00000000 00000000 cipsrvr+0x7382</tt>
> <br><tt>0050fd10 004085b6 0050fd28 00135918 00540232 cipsrvr+0x8c4f</tt>
> <br><tt>0051fd44 0040232d 00000000 00135918 00135918 cipsrvr+0x85b6</tt>
> <br><tt>0051fd90 004039c9 00000000 00135918 00135918 cipsrvr+0x232d</tt>
> <br><tt>0051ffa4 77dc5ac5 00000001 00135920 0012f95c cipsrvr+0x39c9</tt>
> <br><tt>0051ffb4 77e837cd 00135918 00000000 0012f95c
> ADVAPI32!ScSvcctrlThreadW+0xe</tt>
> <br><tt>0051ffec 00000000 77dc5ab7 00135918 00000000
> KERNEL32!BaseThreadStart+0x52</tt><tt></tt>
> <p><tt>eax=ffdff13c ebx=00000050 ecx=beb53b88 edx=8040069a esi=80069590
> edi=c03c9760</tt>
> <br><tt>eip=80447cc5 esp=beb53b30 ebp=beb53b70
> iopl=0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> nv up ei ng nz na po nc</tt>
> <br><tt>cs=0008&nbsp; ss=0010&nbsp; ds=0023&nbsp; es=0023&nbsp;
> fs=0030&nbsp;
> 
>gs=0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> efl=00000286</tt>
> <br><tt>ntoskrnl!MmAccessFault+74e:</tt>
> <br><tt>80447cc5 e9b5000000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> jmp&nbsp;&nbsp;&nbsp;&nbsp;
> ntoskrnl!MmAccessFault+0x74e (80447d7f)</tt>
> <br>&nbsp;
> <p>Damion Wilson wrote:
> <blockquote TYPE=CITE>I have embodied your suggestions and my fixes in
> CIPE-Win32-2.0-pre9, now
> <br>available on <a 
>href="http://CIPE-Win32.sourceforge.net";>http://CIPE-Win32.sourceforge.net</a>.
> I'm anxious to know if you
> <br>get the same uptime I do.
> <p>Thanks, dude
> <p>DKW</blockquote>
> </html>
> 





<< | Thread Index | >> ]    [ << | Date Index | >> ]