Board index » Windows OS » PASSTHRU with ISDN adapter?

PASSTHRU with ISDN adapter?

Windows OS142
Has anyone tried to use PASSTHRU with an ISDN adapter?



For me, it tries to bind, but then either double-free's

the ADAPT structure, or simply fails loading with 'Code

10'. I have not yet modified the PASSTHRU example code.



My ISDN adapter is using standard drivers provided with

Windows 2000 Server.


-
 

Re:PASSTHRU with ISDN adapter?

------=_NextPart_0001_2D531EFC

Content-Type: text/plain

Content-Transfer-Encoding: 7bit





My initial thought is that it should work as long as the ISDN adapter is a

standard NDIS miniport driver and your IM driver's FilterMediaTypes matches

the ISDN driver's LowerRange. There might be an issue with the model that

the ISDN adapter chose between the NDIS WAN model (NDIS v 4 and below) and

the CoNDIS WAN model (NDIS v 5 and above) (see

http://www.microsoft.com/whdc/hwdev/tech/network/CoNDIS-WAN.mspx for more

information) and how the adapter miniport interfaces with the call manager.

More information on the Adapter miniport might be helpful (NDIS version).

Also, turning on NDIS tracing might be helpful.



HTH,



Bryan S. Burgin

bburgin@microsoft.com



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

------=_NextPart_0001_2D531EFC

Content-Type: text/x-rtf

Content-Transfer-Encoding: 7bit



{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}

\viewkind4\uc1\pard\f0\fs20

\par My initial thought is that it should work as long as the ISDN adapter is a standard NDIS miniport driver and your IM driver's FilterMediaTypes matches the ISDN driver's LowerRange. There might be an issue with the model that the ISDN adapter chose between the NDIS WAN model (NDIS v 4 and below) and the CoNDIS WAN model (NDIS v 5 and above) (see http://www.microsoft.com/whdc/hwdev/tech/network/CoNDIS-WAN.mspx for more information) and how the adapter miniport interfaces with the call manager. More information on the Adapter miniport might be helpful (NDIS version). Also, turning on NDIS tracing might be helpful.

\par

\par HTH,

\par

\par Bryan S. Burgin

\par bburgin@microsoft.com

\par

\par This posting is provided "AS IS" with no warranties, and confers no rights.

\par

\par }

------=_NextPart_0001_2D531EFC--



-

Re:PASSTHRU with ISDN adapter?

Ok, I at least got the NDIS debug to show. I forgot that

WFC (Windows File Checler ro something like that) will put

the original ndis.sys file right back again, preventing me

from running the checked version of ndis.sys.



My solution was to delete ndis.sys from the DLL cache

(system32\dll cache\ndis.sys), then put in the checked

version in system32\drivers\.



I used the registry to configure the NDIS debug, but after

loading the ndiskd.dll into WinDbg, I could also control

it from there (now not requiring a reboot).



Now my only issue is to get the actual PASSTHRU to work

for ISDN....I have another, newer, posting on this

newsgroup for that issue.



Thanks,



/ Hannes.





Quote
-----Original Message-----

I actually got PASSTHRU to load (it looks good in the

device manager), by commenting out the following in

miniport.c(line 84), see below.



What is the intention of these few lines of code?



Further down, there's a stack trace from the immediate

crash that occurs when trying to send data across the

ISDN

link. PASSTHRU does not appear anywhere in the stack..?!



Thanks,

Hannes.



=======================================================

//

// Usually we export the medium type of the adapter below

as our

// virtual miniport's medium type. However if the adapter

below us

// is a WAN device, then we claim to be of medium type

802.3.

//



Medium = pAdapt->Medium;

//if (Medium == NdisMediumWan)

//{

// Medium = NdisMedium802_3;

//}



=====================================================













kd>!analyze -v

**********************************************************

*

********************

*



*

* Bugcheck

Analysis *

*



*

**********************************************************

*

********************



DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

An attempt was made to access a pagable (or completely

invalid) address at an

interrupt request level (IRQL) that is too high. This is

usually

caused by drivers using improper addresses.

If kernel debugger is available get stack backtrace.

Arguments:

Arg1: 00000000, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write

operation

Arg4: 00000000, address which referenced memory



Debugging Details:

------------------





READ_ADDRESS: 00000000



CURRENT_IRQL: 2



FAULTING_IP:

+0

00000000 ?? ???



DEFAULT_BUCKET_ID: DRIVER_FAULT



BUGCHECK_STR: 0xD1



LAST_CONTROL_TRANSFER: from 804293f5 to 804535ac



STACK_TEXT:

f7f81534 804293f5 00000003 f7f8157c 00000000 nt!

RtlpBreakWithStatusInstruction

f7f81564 804299e8 00000003 00000000 00000000 nt!

KiBugCheckDebugBreak+0x31

f7f818f0 804663dc 00000000 00000000 00000002 nt!

KeBugCheckEx+0x390

f7f818f0 00000000 00000000 00000000 00000002 nt!

KiTrap0E+0x27c

f7f8197c f87c0824 81c258a8 81c0e3d4 81c0f8e4 0x0

f7f819a0 f1f6fd20 81c1ab68 81c0e3d4 81c0f8e4 NDIS!

ndisMWanSend+0xd8

f7f819cc f1f6e007 81c469d4 81c467a8 81c49e8c ndiswan!

SendOnLegacyLink+0xd4

f7f81a30 f1f713f5 00000018 0000002a 00000001 ndiswan!

FramePacket+0x279

f7f81a70 f1f6dda7 81c49888 81c49e01 f7f81aa7 ndiswan!

SendFromPPP+0x123

f7f81aa8 f1f7153f 81c49800 00000000 81c0f008 ndiswan!

SendPacketOnBundle+0x62

f7f81ad0 f1f71a6c 81c467a8 81c49888 81c42028 ndiswan!

BuildIoPacket+0x199

f7f81af8 f1f7177c 81c0f008 000005f0 81c0f008 ndiswan!

IoSendPacket+0xf3

f7f81b14 f1f71718 0000000a 81c0f008 000005f0 ndiswan!

ExecuteIo+0x26

f7f81b4c f87ac952 81f158f0 00000000 81c673a8 ndiswan!

NdisWanIoctl+0x80

f7f81b60 f87ac7aa 81f158f0 81c673a8 81f158f0 NDIS!

ndisDummyIrpHandler+0x34

f7f81c0c 8041cc8b 81f158f0 81c673a8 81c673a8 NDIS!

ndisDeviceControlIrpHandler+0x62

f7f81c20 804ac692 81c0f5f8 00000000 81c673a8 nt!

IopfCallDriver+0x35

f7f81c34 804ad4c6 81f158f0 81c673a8 81c6d4a8 nt!

IopSynchronousServiceTail+0x60

f7f81d00 804a52f8 00000340 000003a1 00000000 nt!

IopXxxControlFile+0x5ba

f7f81d34 80462f14 00000340 000003a1 00000000 nt!

NtDeviceIoControlFile+0x28

f7f81d34 77f88363 00000340 000003a1 00000000 nt!

KiSystemService+0xc4

0121fa70 77e89402 00000340 000003a1 00000000 ntdll!

ZwDeviceIoControlFile+0xb

0121fad4 757237e5 00000340 00120028 000ae7d0 KERNEL32!

DeviceIoControl+0x7a

0121fb08 75720b1b 000c8940 000ae7c8 000aedc0 rasmans!

PortSendRequest+0x9a

0121fb20 774c1658 000ae7b0 000009e4 0121fb90 rasmans!

ServiceRequest+0x69

0121fb34 774c158d 00000000 000ae7b0 000009e4 RASMAN!

PutRequestInQueue+0x17

0121fb74 774c41b4 00000000 00000006 0000000b RASMAN!

SubmitRequest+0xbd

0121fb8c 75918549 0000000b 000e29e8 0000002a RASMAN!

RasPortSend+0x2d

0121fba4 75913fe2 011d3a18 0000002a 00000000 rasppp!

PortSendOrDisconnect+0x15

0121fbc0 75913669 011d3b14 0000002a 00000000 rasppp!

FsmSendConfigReq+0xc2

0121fbdc 7591902c 011d3a18 00000000 7592e608 rasppp!

FsmUp+0x74

0121ff7c 759191d4 011d2470 00000000 7591895d rasppp!

ProcessLineUpWorker+0x656

0121ff88 7591895d 011d2470 0114fbdc 0114fbf4 rasppp!

ProcessLineUp+0x18

0121ffb4 77e8b2d8 00000000 0114fbdc 0114fbf4 rasppp!

WorkerThread+0xd4

0121ffc0 0114fbf4 00000000 7ffa2000 751775a8 KERNEL32!

BaseThreadStart+0x52

WARNING: Frame IP not in any known module. Following

frames may be wrong.

0114fbdc 00000000 00000000 00000000 00000000 0x114fbf4





FAILED_INSTRUCTION_ADDRESS:

+0

00000000 ?? ???



FOLLOWUP_IP:

ndiswan!SendOnLegacyLink+d4

f1f6fd20 8acb mov cl,bl



FOLLOWUP_NAME: MachineOwner



SYMBOL_NAME: ndiswan!SendOnLegacyLink+d4



MODULE_NAME: ndiswan



IMAGE_NAME: ndiswan.sys



DEBUG_FLR_IMAGE_TIMESTAMP: 3cdac98b



STACK_COMMAND: kb



BUCKET_ID: 0xD1_CODE_AV_BAD_IP_ndiswan!

SendOnLegacyLink+d4



Followup: MachineOwner

---------









.



-