DeviceIoControl returns no data (WinCE 4.2)

kernel debugger on Win CE??!!! I'm not aware of such tools.

Oh... Also,.. I guess I forgot to mention, MYDriver.dll Actually works on
Win CE 5.0 (CEPC) as well!!! only not on WinCE 4.2..???
my CE 4.2 is a HP iPAQ h6320 device with built-in GPRS/WiFi/Bluetooth...

on CEPC (CE 4.2) MYDriver.dll and Application.dll are part of OS (Built-in
the OS) so then Application.dll sends DeviceIoControl and driver returns
data....
on CE 4.2 I tried loading MYDriver.dll at boot time but application starts
later and this is where NDISUIO returns data but MYDriver.dll (Or
DeviceIOControl) returns no data available... so how could something be
broken when it works on CEPC 5.0 unless there is a main structural
difference between the two version.?? is there??

Where can I find a well documented step-by-step procedure in how to install
a NDISProtocol Driver on CE 4.2 actual device??

Any other feedback??

"Steve Maillet (eMVP)" <nospam1.TakeThisOut@EntelechyConsulting.com> wrote in message
news:ebQec1RyFHA.2076@TK2MSFTNGP14.phx.gbl...
> Step through the code with the kernel debugger and see why it's returning
> that code. Obviously something got broken in your modifications of the
> original.
>
> --
> Steve Maillet
> EmbeddedFusion
> www.EmbeddedFusion.com
> smaillet at EmbeddedFusion dot com
>
>

The kernel debugger is the one built into platform builder. It is
indispensable when doing NDIS development.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

"The Amazing" <theamazing.TakeThisOut@nowhere.com> wrote in message news:ukYShoRyFHA.3720@TK2MSFTNGP11.phx.gbl...
> All..
> we are trying to run a dll almost exaclty same as sample NDISUIO protocol
> driver on an actual Win CE 4.2 OS based device.
> we have created a GUI that talks to this driver... here is the issue,
> Our GUI can send DeviceIOControl call to NDISUIO.dll and receive the binding
> information.

Do you load your "ndisuio" DLL directly into your application
(rather than running it as driver in the device manager process)?

--PA

> But when we create an exact framework of NDISUIO.dll and call it
> MYDriver.dll then when GUI sends DeviceIOControl then it actually returns
> "No Data Available". (I belive the return code is 259)
> we have checked all the registry key, index and everything with all the
> correct name... GUI returns OK after OPen and Create... so it seems that it
> is able to load the MYDriver.dll correctly but not the rest...
> Any idea what could be the problem or what we are missing here??
> we also tried by disabling the running NDISUIO.dll on the wince and have
> only MYDriver.dll but yet the same issue...
> thank you in advance for your feedback.
>
>

huummm!!! you mean when GUI sends the request to MYDriver.dll I have to load
"ndisuio" to my application??? would you explain a bit more please?
Again I do exactly the same thing as on both GUI to ndisuio.dll and to
MYDriver.dll.... unless since ndisuio.dll is a built-in to OS from MSFT it
is already somehow registered that I miss that with MYDriver.dll
registration???
I would greatly appreciate some more suggestions.

"Pavel A." <pavel_a DeleteThis @NOwritemeNO.com> wrote in message
news:ODPOxyZyFHA.664@tk2msftngp13.phx.gbl...
> "The Amazing" <theamazing DeleteThis @nowhere.com> wrote in message
news:ukYShoRyFHA.3720@TK2MSFTNGP11.phx.gbl...
> > All..
> > we are trying to run a dll almost exaclty same as sample NDISUIO
protocol
> > driver on an actual Win CE 4.2 OS based device.
> > we have created a GUI that talks to this driver... here is the issue,
> > Our GUI can send DeviceIOControl call to NDISUIO.dll and receive the
binding
> > information.
>
> Do you load your "ndisuio" DLL directly into your application
> (rather than running it as driver in the device manager process)?
>
> --PA
>
> > But when we create an exact framework of NDISUIO.dll and call it
> > MYDriver.dll then when GUI sends DeviceIOControl then it actually
returns
> > "No Data Available". (I belive the return code is 259)
> > we have checked all the registry key, index and everything with all the
> > correct name... GUI returns OK after OPen and Create... so it seems that
it
> > is able to load the MYDriver.dll correctly but not the rest...
> > Any idea what could be the problem or what we are missing here??
> > we also tried by disabling the running NDISUIO.dll on the wince and have
> > only MYDriver.dll but yet the same issue...
> > thank you in advance for your feedback.
> >
> >
>
>

"The Amazing" wrote:
> huummm!!! you mean when GUI sends the request to MYDriver.dll I have to load
> "ndisuio" to my application???

No, of course not! I just asked, maybe you did something like this.
Since all these drivers in CE are DLLs, it is easy to mistake.
From your previous post it wasn't clear how do you call ndisuio,
and what is your driver (NDIS miniport?)

Regards,
--PA

driver is the NDISProtocol driver.... By now I'm pretty sure that the
problem is due to the installation of the driver on the Win CE device not
the CEPC.... Is there a step-by-step proecedure somewhere to say exactl
"Pavel A." <pavel_a.DeleteThis@NOwritemeNO.com> wrote in message
news:53AD74DC-638A-4234-A35A-D52020AF057D@microsoft.com...
> "The Amazing" wrote:
> > huummm!!! you mean when GUI sends the request to MYDriver.dll I have to
load
> > "ndisuio" to my application???
>
> No, of course not! I just asked, maybe you did something like this.
> Since all these drivers in CE are DLLs, it is easy to mistake.
> From your previous post it wasn't clear how do you call ndisuio,
> and what is your driver (NDIS miniport?)
>
> Regards,
> --PA
>

Mydriver is the Ndis Protocol driver.... I'm pretty sure it should be the
installation on Win CE device... is there a step-by-step procedure for
installation and a method to assure the correct installation of the deriver
on the actual device?

Regards,
TA
"Pavel A." <pavel_a DeleteThis @NOwritemeNO.com> wrote in message
news:53AD74DC-638A-4234-A35A-D52020AF057D@microsoft.com...
> "The Amazing" wrote:
> > huummm!!! you mean when GUI sends the request to MYDriver.dll I have to
load
> > "ndisuio" to my application???
>
> No, of course not! I just asked, maybe you did something like this.
> Since all these drivers in CE are DLLs, it is easy to mistake.
> From your previous post it wasn't clear how do you call ndisuio,
> and what is your driver (NDIS miniport?)
>
> Regards,
> --PA
>

Here is something you need to check.

1. Set a break point in your driver IoControl function or display some
trace from that function.
2. Making the IoControl call from your application. If your driver
IoControl is not called or return an error code, you can know what the
problem is immediately.


"The Amazing" <theamazing.RemoveThis@nowhere.com> wrote in message
news:uyGtuAcyFHA.464@TK2MSFTNGP15.phx.gbl...
> huummm!!! you mean when GUI sends the request to MYDriver.dll I have to
> load
> "ndisuio" to my application??? would you explain a bit more please?
> Again I do exactly the same thing as on both GUI to ndisuio.dll and to
> MYDriver.dll.... unless since ndisuio.dll is a built-in to OS from MSFT it
> is already somehow registered that I miss that with MYDriver.dll
> registration???
> I would greatly appreciate some more suggestions.
>
> "Pavel A." <pavel_a.RemoveThis@NOwritemeNO.com> wrote in message
> news:ODPOxyZyFHA.664@tk2msftngp13.phx.gbl...
>> "The Amazing" <theamazing.RemoveThis@nowhere.com> wrote in message
> news:ukYShoRyFHA.3720@TK2MSFTNGP11.phx.gbl...
>> > All..
>> > we are trying to run a dll almost exaclty same as sample NDISUIO
> protocol
>> > driver on an actual Win CE 4.2 OS based device.
>> > we have created a GUI that talks to this driver... here is the issue,
>> > Our GUI can send DeviceIOControl call to NDISUIO.dll and receive the
> binding
>> > information.
>>
>> Do you load your "ndisuio" DLL directly into your application
>> (rather than running it as driver in the device manager process)?
>>
>> --PA
>>
>> > But when we create an exact framework of NDISUIO.dll and call it
>> > MYDriver.dll then when GUI sends DeviceIOControl then it actually
> returns
>> > "No Data Available". (I belive the return code is 259)
>> > we have checked all the registry key, index and everything with all the
>> > correct name... GUI returns OK after OPen and Create... so it seems
>> > that
> it
>> > is able to load the MYDriver.dll correctly but not the rest...
>> > Any idea what could be the problem or what we are missing here??
>> > we also tried by disabling the running NDISUIO.dll on the wince and
>> > have
>> > only MYDriver.dll but yet the same issue...
>> > thank you in advance for your feedback.
>> >
>> >
>>
>>
>
>

It seems the built-in vs. added later is your issue. How are you
"loading MYDriver.dll at boot time"? The built-in case causes device.exe
to load your driver and it calls your driver's xxx_Init function.

Look in PB help for ActivateDevice/ActivateDeviceEx for info on how to
load drivers dynamically.

The Amazing wrote:
> kernel debugger on Win CE??!!! I'm not aware of such tools.
>
> Oh... Also,.. I guess I forgot to mention, MYDriver.dll Actually works on
> Win CE 5.0 (CEPC) as well!!! only not on WinCE 4.2..???
> my CE 4.2 is a HP iPAQ h6320 device with built-in GPRS/WiFi/Bluetooth...
>
> on CEPC (CE 4.2) MYDriver.dll and Application.dll are part of OS (Built-in
> the OS) so then Application.dll sends DeviceIoControl and driver returns
> data....
> on CE 4.2 I tried loading MYDriver.dll at boot time but application starts
> later and this is where NDISUIO returns data but MYDriver.dll (Or
> DeviceIOControl) returns no data available... so how could something be
> broken when it works on CEPC 5.0 unless there is a main structural
> difference between the two version.?? is there??
>
> Where can I find a well documented step-by-step procedure in how to install
> a NDISProtocol Driver on CE 4.2 actual device??
>
> Any other feedback??
>
> "Steve Maillet (eMVP)" <nospam1 DeleteThis @EntelechyConsulting.com> wrote in message
> news:ebQec1RyFHA.2076@TK2MSFTNGP14.phx.gbl...
>
>>Step through the code with the kernel debugger and see why it's returning
>>that code. Obviously something got broken in your modifications of the
>>original.
>>
>>--
>>Steve Maillet
>>EmbeddedFusion
>>www.EmbeddedFusion.com
>>smaillet at EmbeddedFusion dot com
>>
>>
>
>
>


--
Tony Paille
NetStorm Consulting
paille (a t) netstorm (d o t) mb (d o t) ca