Re: [Libusb-win32-devel] libusb-win32 weird problem with 0.1.12.0 on XP SP1, but works with 0.1.10.1

[Spiro T. <an-...@sp...>]

Hello Stephan,

* On Sat, Mar 17, 2007 at 11:20:40AM +0100 Stephan Meyer wrote:
 
> The correct version is 0.1.12.0. I fixed it.

Thank you. I expected it that way, but I was not sure.


> > Note that opencbm-xu1541.dll is dynamically loaded by opencbm.dll by
> > using LoadLibrary(), GetProcAddress(), and FreeLibrary afterwards.
> 
> It should make no difference whether the DLLs are "statically linked" or
> loaded at runtime.

I believe this, too. Anyway, I also thought that it should not make any
difference regardless of which run-time library is used for which part,
but it is not. Thus, I reported this for completeness.
 
> I'm no DLL expert either but it's usually good practice to link all system
> libraries such as msvcrt.dll dynamically because:
> 
> * this saves memory and disk space
> * speeds up application startup
> * ensures that all components of an application use exactly the same 
>    library/DLL versions

Well, at least the DDK samples do not use MSVCRT.DLL, but use the
default (single-threaded statically linked library). That's the reason
why I used this approach, too.


> > Have a look into _usb_io_sync(), line 1170 of windows.c: It fails with
> > error code 0xc0000005 (access violation). I can clearly see in the
> > debugger that the memory referenced by the pointer out is valid, as is
> > the data referenced by the pointer in. I can follow the OS function
> > DeviceIoControl() until the SYSENTER. All pointers up to there are valid
> > and correctly used. Doing the next step, I get the access violation.
> 
> Have you verified that all parameters passed to DeviceIoControl() are
> valid and correct? Please check the 'ol' parameter. Is it corrently initialized
> and is 'ol.hEvent' valid?

This was a very good hint!

I looked again and found that the input buffer "in" and "in_size" is not
null if _usb_io_sync() is called. I set them to NULL in case we want to
output anything on the USB bus, cf. the patch attached.  With this,
everything works fine!

Note that the in buffer in is initialized with the input parameter bytes
in usb_control_msg(). Now, the "bytes" parameter I give is just a
constant string parameter. It seems my compiler puts it into a memory
area which is not writable; thus, the 0xc0000005 "no access" occurs.

I am not sure if my fix is the right solution for everyone. I don't know
if usb_control_msg() can give back data even if this is an output call.
Anyway, at least for all my tests, it solved the problem for me.


> > To be honest, I don't have a clue what is really going on, and how this
> > can be solved.
> > 
> > Unfortunately, I cannot debug this better, as
> > 
> > 1. I don't have a second XP based machine to debug the call into
> >    kernel-mode, too, and
> > 
> > 2. somehow, I have not managed to get libusb-win32 claim the device
> >    inside of VMWare (which would allow me to debug the kernel calls,
> >    too).
> 
> Where does the crash and the access violation occur? In user-space
> or in kernel space? Do you get a BSOD?

As I told, the crash is gone if I link my DLL against MSVCRT.DLL, which
I am doing currently.

The access violation is reported as a normal GetLastError() result. It
occurs after the call to SYSENTER, thus, I am perfectly sure that it
happens in kernel-mode.

I have done some more debugging: I added some outputs in the dispatch()
routine in the driver libusb0.sys. It is not called from _usb_io_sync()
if I get the access violation. So, I conclude that it is not your driver
which reports this access violation, but the operating system.

Still, I don't know yet where exactly this happens, and which parameter
is the culprit.


So: With MSVCRT, I do not get any crash. Even if I do not use MSVCRT, I
don't get a BSOD. I just get that pop-up window, telling me that there
was a memory access (read) that should not have been there.

> If the access violation occurs in user-space then debugging in kernel-space
> won't make much sense.

Yes, of course.

> > I thought I might have some problem with the initialization of the CRT.
> > For this, I changed all DLL entry points in my code to DllEntry();
> > anyway, the problems did not go away.
> 
> Thanks for the link. I changed the DLL's entry point to _DllMainCRTStartup@12 
> as recommended by the article. A new version is attached. Please give it a try.

I am sorry, the attachment is empty here.


So, to summarize: IF I link my DLL against MSVCRT, and I use the
attached patch, everything works fine for me (now).

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis                              http://opencbm.sf.net/
http://www.trikaliotis.net/                     http://www.viceteam.org/