I wrote a WIA microdriver that currently only produces dummy data - later on it should acquire data from a scanner.
The MicroEntry() and SetPixelWindow() functions are called as expected, then Scan(SCAN_FIRST,...) is called and Scan(SCAN_NEXT,...) is called multiple times.
Then I get an error (message has no special meaning) - both when using "Windows Live Image Gallery" and when using "Windows Fax and Scan". I use Windows 7, 64-bit.
I tried to use the official WIA microdriver example from the Windows Driver Kit. I cannot see which functions are called in which order but I get an error message using both programs, too.
Because the official driver from Microsoft does also not work I think the problem is not in my program but somewhere in the OS.
My questions:
Is there any known reason why these drivers do not work?
Is there any work-around?
Thanks.
I found out the answer myself:
The official example microdriver has a bug! Because I used that driver as template for my own one my driver had the same bug.
The problem is that the last argument of the "Scan()" function is NULL in the SCAN_FINISH phase but the example driver will always write 0 to the location this pointer points to.
I wonder why Microsoft didn't find this bug because it will always lead to an exception in the driver!
Related
I have an application in windows, that opens a com port. It attempts to call a comport, then fails and prompts me with an error.
The issue is this is very legacy software that we no longer have the source code for. I'm wondering if anyone knows of a way that can trace, or follow a program calling a com port to find out what com port its attempting to allocate.
Appearantly you can use Process Explorer (as called out in this post) to search for processes using serial ports. It sounds like you should be able to use the same searching concept called out the other post to find what you need.
I actually gave up on this solution and re-wrote the entire program in a week, it had to be done due to binary compatibility issues with the PCI cards.
We're currently working on an art project where we're recording video with GSvideo library and showing another video simultaneously with VLC. Our project works fine on three Windows 7 computers we have tried, but the ones we have available for the exhibition gives the following error:
Exception in thread "Animation Thread" java.lang.UnsatisfiedLinkError:
can't load library gio-2.0 (gio-2.0|libgio-2.0|libgio-2.0-0) with
-Djna.library.path=//Desktop/media_art_installation/sktetch/libraries/GSVideo/library\gstreamer\windows64.
Last error:java.lang.UnsatisfiedLinkError: Unable to load library
'gio-2.0': The specified module could not be found.
We noticed that the path includes both "/" and "\". We know that our school computers use Java 1.6. Neither we or our teachers or tech support can find the answer to our question. So, why doesn't it work on school computers?
The line that gives the error in our code is as follows:
movieMaker = new GSMovieMaker(this, 640, 480, "data/" + getCurrentFileName(), GSMovieMaker.THEORA, GSMovieMaker.MEDIUM, fps);
For now let's assume the spelling of the library path is not the problem...
If you parse the error you mention, you see that it cannot find the module. It lists a library path, which must be incorrect on the machines used for exhibition. Were the Win 7 machines 32- or 64-bit? What type of machines are used for exhibition? (Win XP? Macs? 32-bit 64-bit). Any difference between the test and exhibition machines would be a red flag.
Also, how are you pointing to this library? After Googling a bit I've come up with the following:
A thread on sourceforce recommends using the GSVideo.localGStreamerPath to point to the gstreamer library.
Another thread noted that using System.loadLibrary solved the problem (second to last post in thread).
So the second suggestion might look like this for you:
System.loadLibrary("/Desktop/media_art_installation/sketch/libraries/GSVideo/library/gstreamer/windows64");
Under what circumstances does SetupAPI's SetupUninstallOEMInf function set the ERROR_NO_MORE_ITEMS error code?
The MSDN documentation does not detail this.
Apparently the ERROR_NO_MORE_ITEMS error code can indicate there are still installed devices using this .INF file (and the SUOI_FORCEDELETE flag wasn't specified).
Reading %windir%\setupapi.log (on XP) or %windir%\Inf\setupapi.dev.log (on Vista and higher) can be helpful to determine what SetupAPI is really trying to say.
I am currently trying to build an application, that will talk to the super IO chip using port IO. As part of that, I am trying to develop a kernel-mode windows driver that I can contact, and which will do the IO for me. I have therefore downloaded the Windows Driver Kit v7.1.0, build 7600.16385.1, and I am trying to compile and install the sample portio driver, which is provided by WDK, since it seems to be quite close to what I need.
I have compiled the driver in both free and checked x86 XP build environments. This works fine, but when I try to install the resulting driver, using the provided instructions - which basically just amount to using the Add Hardware Wizard, and then supplying the files manually - I get the following error:
-The following hardware was installed: Sample PortIO Driver (KMDF)
-The software for this device is now installed, but may not work correctly
-Windows cannot load the driver for this hardware. The driver may be corrupted or missing. (Code 39)
So, I see two explanations: corrupted or missing. Missing, as far as I can tell, given my environment variables and .inf file, would mean that the generated .sys file is not in c:\windows\system32\drivers, but when I look there, the file is there.
So that would mean that the file is corrupted. Given that I haven't touched the driver code, and that I have found others with the same problem, it doesn't seem to be a problem with my compilation, but rather with the code itself, or some common combination of machine type and code. But I may be wrong.
Does anybody have any suggestions on how to solve this?
I would recommend enabling SetupAPI logging as described in the following document from Microsoft:
http://www.microsoft.com/whdc/archive/setupapilog.mspx
For Windows 7, the log files are split up as described here:
http://support.microsoft.com/kb/927521
You may be able to isolate the problem with the additional information in the SetupAPI logs.
The specific problem is, the support of condition variable on Windows begins from Vista, for early version of Windows (Windows XP), I have a emulated condition variable code sort of solved the problem. However, I'd like to have the ability to call native condition variable API when the system supported and fallback to my version only on XP and earlier version. I tried to detect windows version with GetVersionInfo API, but it still gives me error on start time (cannot find API entry of InitializeConditionVariable sort of).
I am not familiar with Windows programming, how do you solve the gentle fallback problem nicely?
if you want to call a function that may or may not exist depending on platform version then use dynamic loading
LoadLibrary and GetProcAddress
These will tell you if the entry point exists and then let you call it if it does