Re: [Libusb-win32-devel] =?iso-8859-15?q?libusb-win32_weird_problem_w?= =?iso-8859-15?q?ith_0=2E1=2E12=2E0_on_XP_SP1=2C_but_works_with_0=2E1=2E10?= =?iso-8859-15?q?=2E1?=

[Stephan M. <ste...@we...>]

Thanks for the patch! I'll apply it and release
version 0.1.12.1.

Stephan


> 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/
> 
> 
> <hr>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> <hr>
> _______________________________________________
> Libusb-win32-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
> 
> 


_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192