Frequently Asked Questions - Driver Development Tools

With WinDriver I don't have to program in the kernel mode. So I'm not really creating a driver, am I?
A device driver is a software module that controls hardware. In today's operating systems, this software module usually resides in the kernel mode (ring 0). However, WinDriver enables you to write this code in the user mode, utilizing our lower-level kernel driver (windrvr6/.sys/.o/.ko or windrvr/.sys/.vxd/.o - depending on your OS and WinDriver version), and thus frees you from the need for any driver development knowledge. For a better understanding of the basic WinDriver architecture, refer to the WinDriver Architecture page on our site.
WinDriver also includes the Kernel PlugIn feature, which allows you to 'drop' sections of your user-mode code into the kernel mode for better performance and greater flexibility (for PCI/CardBus/PCCMIA/PCI Express/ISA).
Whether the code you develop resides in the user mode or the kernel mode, it is still the code driving the hardware, and therefore it is a driver (but you can call it anything you like...).

Why should I buy WinDriver and not develop a device driver on my own?
Using WinDriver, you gain the following benefits:

• Cost - Save 90% of the development time.
  
  
• Reliability - WinDriver has been market tested thoroughly in thousands of applications (see the Testimonials page for more on this). It has been debugged on almost every platform in the market. Therefore it not only speeds your development time, but cuts your debugging time as well.
  
  
• Time to market - WinDriver is ready for you today. Using WinDriver will drastically shorten your development cycle.
  
  
• Flexibility - WinDriver supports multiple operating systems, such as Windows Vista, Server 2003, XP, 2000, NT 4.0, Me, 98, Windows CE, Linux, Solaris, and VxWorks (depending on the version you are using) - so even if you only need your driver on one platform today, using WinDriver gives you the flexibility of running under any platform tomorrow. (Please refer to Technical Document #4 for a list of the supported operating systems for each type of hardware - PCI/ISA/USB).
  
  
• Stability - WinDriver keeps you away from the OS kernel. While our pre-written kernel module is doing all the transactions with your hardware, you write your code in the protected application mode. This way you get a kernel mode driver (written by our experienced developers), which was tested on practically any OS/platform/BIOS combination available and was found rock stable.
  
  

Must I have experience in device driver or kernel programming?
Not at all. With WinDriver, you are coding your device driver in the user mode. WinDriver already provides you with the lower level kernel mode driver (windrvr6/.sys/.vxd/.o/.ko or windrvr/.sys/.vxd/.o - depending on your OS and WinDriver version), which implements the WinDriver API (see the WinDriver Architecture page on our site). You can, therefore, use your favorite development environment to program and debug your driver, in the user mode, thereby drastically decreasing your device driver development time.

Recommended development steps:

1. Open the DriverWizard (WinDriver/wizard/wdwizard). On Windows, you can also run the DriverWizard using the shortcut icon on your desktop or from Windows' Start-up menu (Start --> Programs --> WinDriver --> DriverWizard).
   
   
2. Use the graphical DriverWizard to easily diagnose your hardware, without writing a single line of code. For PCI/ISA - read/write the hardware resources (memory/IO/registers) and listen to interrupts.
   For USB - transfer data on the pipes, reset the device, etc.
   
   
3. Select the "Generate Code" option from the Toolbar, or press the "Next>>" button. Select your target compiler and let the DriverWizard create a skeleton of a device driver application for your device. The generated code will include convenience structures and functions, which utilize WinDriver's basic API to access the resources detected and defined (by you) for your hardware.
   
   You can use the DriverWizard to generate code in C, Delphi (Pascal) or Visual Basic. The DriverWizard will also create makefiles and the relevant build environment for leading 32-bit compilers (such as MSDEV, Borland C++ Builder and Borland Delphi).
   
   You can also use one of the WinDriver samples as the basis for your development. Specific samples for enhanced-support hardware can be found under the relevant directory for that hardware, such as PLX, Altera, Cypress, etc. - see the WinDriver User's Manual for more information regarding WinDriver's enhanced support for specific PCI and USB chip sets. General samples can be found under the WinDriver/samples (C), WinDriver/vb/samples (Visual Basic) and WinDriver/delphi/samples (Delphi/Pascal) directories. Beginning with version 7.00 of WinDriver you can also find .NET samples in the WinDriver/csharp.net (C#) and WinDriver/vb.net (VB.NET) directories.
   
   
4. Use the manual and help files to modify the generated diagnostics code and add the specific functionality that you need (if any), in accordance with your hardware's specification.
   
   The WinDriver User's Manual and help files are found in the WinDriver/docs directory and can also be accessed via Windows' Start-up menu (for Windows users). All documents are also available on-line from the WinDriver Support Page page.
   
   
5. Compile and build your code (from the user mode!) using any 32-bit compiler.

DONE!

Can I try before I buy?
Yes. Jungo provides full-featured evaluation versions for both the WinDriver and KernelDriver tool-kits. The trial versions can be downloaded from the Downloads page on our site. The limitations of each evaluation version (as compared with the registered version) are outlined in the WinDriver User's Manual and in Technical Document #9.

Is WinDriver fully backwards compatible?
Yes. All versions of WinDriver are backwards compatible.
For example: Code compiled with WinDriver v4.32 will work, without recompilation, after replacing the windrvr.sys/vxd file for v4.32 with the driver file from version 5.05 (although for PCI/USB hardware on Windows Vista/Server 2003/XP/2000/98/Me, you may also need to replace the INF file for the device to one registered with the DriverWizard from the newer version).
However, in version 6.00 we have modified the name of the lower level kernel module to "windrvr6" (instead of "windrvr"), therefore to use code developed with an earlier WinDriver version (v5.22 and below), you must first rebuild the code with the header files from the new version (see Technical Document #116), although old API will still be supported, for backwards compatibility, after rebuilding the code. To fully utilize the improvements of any new version, it is recommended, however, to always use the newest API.

I wanted to know if you have a tool for VxWorks?
There is a WinDriver tool-kit for VxWorks, called DriverBuilder for VxWorks, which supports the following Board Support Packages (BSPs):

• Intel x86 CPU with any Intel x86 BSP (pc486.pcPentium/pcPentiumPro).
• PPC 821/860 with MBX821/860.
• PPC 750 (IBM PPC 604) with MCP750.

DriverBuilder is designed for the Tornado II environment.
Please see the DriverBuilder Installation Instructions for set-up and installation instructions for DriverBuilder for VxWorks.

How do I report a problem effectively?
You can use our Secured Support Center (or the Non-Secured Support Center), or send an email to: support@jungo.com.
To ensure that you specify all the relevant information and receive a quick reply, please use the on-line form. You can also call by telephone. If you call outside our office hours or if all support personnel are occupied, please leave your full contact details (name, company name, email and phone numbers) and we will be sure to contact you shortly.

When reporting a support problem by email, please include a clear description of all the steps you performed, and specify which step failed and what was the exact nature of the failure or erroneous behavior that you encountered (including complete error messages).

Please check specifically that you have included the following information:

1. In general, please indicate:
   
   • Your operating system. For example: Windows Vista 64-bit; Windows 2000 SP3; Windows CE v5.0; RedHat Linux 7.2 kernel version 2.2.14-20.
     
     
   • Your WinDriver version. For example: 9.00; 8.02; 5.22.
     
     
   • The entire output of the Debug Monitor utility (wddebug_gui, or wddebug for platforms without graphical support): Run the Debug Monitor, set the debug level to 'Trace', reproduce your problem and attach the output from the Debug Monitor window (including the version information at the top).
     
   
   
2. For licensing problems: In addition to the Debug Monitor log, please be sure to specify your full license registration string, which you received when purchasing the software, and your development computer's registration code. You can view the license registration string and the PC registration code from the DriverWizard's Licensing Information window (File --> Registeration Options).
   
   
3. For PCI related problems: In addition to the Debug Monitor log, please also attach the entire output of the pci_dump utility (found in the WinDriver/util directory), and be be sure to specify your card's vendor ID and device ID as well.
   
   
4. For installation related problems, in addition to the Debug Monitor output, be sure to specify the exact installation steps that you performed (which files were copied to which directories; usage of the wdreg installation utility; installation of INF files; etc.) and the result of each step, and attach a copy of the exact error message that you received (if any).
   On Plug-and-Play Windows platforms (Windows Vista/Server 2003/XP/2k/Me/98), please also attach a copy of the device INF file that was used in the installation (if any), and a copy of the %WINDIR%\setupapi.log file from the PC on which the problem occurred.
   
   

I installed WinDriver on a Windows PC about 40 days ago and forgot about it. Now, when I try to evaluate it I get a message notifying me that the evaluation period expired. Uninstalling and reinstalling the software does not help.
Please contact sales@jungo.com to request an extension of the evaluation period. Please also refer to the WinDriver User's Manual and to Technical Document #9 for a description of the evaluation limits of the different WinDriver/KernelDriver kits.

I need a driver for a Microsoft Side Winder with USB port. Can you provide me with a driver for it?
Jungo provides tool kits for writing device drivers. We do not provide ready-made drivers. For a ready-made driver you can check out one of the sites listed on the following page: http://www.jungo.com/resource_index4.html.

How do I uninstall WinDriver from my computer?
To completely remove WinDriver from your computer, follow the instructions found at the Uninstall Page on our site. NOTE: The on-line uninstallation instructions are for the latest WinDriver version. If you are using an older version, follow the uninstallation instructions in the WinDriver User's Manual for your specific version.

Back to Top

How do I purchase my WinDriver license?
Simply order the product from our On-line Store or download a Text Order Form and email it to: sales@jungo.com, or Fax it to us to the numbers indicated in the contact details on our site for the Driver Tools and Software Components department.

What will I receive with my license?
Your registered license will include the registered WinDriver version, official documentation and 2 months of free product upgrades and technical day support.

How do I get technical support and maintenance after 2 months?
To get technical support or be eligible for version upgrades after the expiration of the complimentary two months support and maintenance period, you must subscribe to the WinDriver/KernelDriver annual Upgrade & Support plan. You can subscribe to this plan from the On-Line Store (when purchasing the subscription with the original license purchase) or from our On-Line Support Store, or download a relevant order form from our site and email it to: sales@jungo.com or Fax it to: +972-9-885-9366 (US toll free Fax number: 1-877-514-0538).
For more information regarding the support & maintenance plan, please refer to the Support Purchase page. A full price list can be found in the On-line Support Store (the price is derived from the price of the original license). As you can see in the aforementioned pages, it is much cheaper to subscribe to the upgrade and support plan during the period of a current valid upgrade & support subscription (including the 2 months complimentary upgrade & support period). Once you subscribe to this plan, use Jungo's Secured Support Center (or the Non-Secured Support Center) to contact our support team at any time. Please also refer to the following FAQ: http://www.jungo.com/support/faq.html#lfc to find out how to report a problem effectively.

How many copies of my driver can I distribute, after developing it with WinDriver? Must I pay royalties?
After purchasing the license from Jungo, you own your driver. The license is issued for the development stage. The executable/DLL that you create is yours to distribute freely, in as many copies as you wish. No royalties are to be paid to Jungo. The only exception to this is if you have created a driver development kit with WinDriver/KernelDriver. For this reason you cannot distribute the WinDriver/KernelDriver header files or your license registration string, thereby enabling others to develop a driver with WinDriver/KernelDriver. For more information, take a look at the "Distributing Your Driver - Legal Issues" Appendix in the WinDriver/KernelDriver User's Manual or contact sales@jungo.com.

After registering my evaluation version of WinDriver, my WinDriver application (which worked with the evaluation version) does not work unless I first run the DriverWizard. Once I reboot the PC, the program stops working again, until I start the DriverWizard. This is also true for the WinDriver sample programs. What is wrong?
When using a registered version of WinDriver/KernelDriver, you must register your specific license registration string from the code.

The generated DriverWizard code for the registered tool-kit will already include the relevant code for registering your license (provided you have activated your license from the wizard before generating the code). However, if you used the DriverWizard to generate the code during the evaluation period, or if you are using one of the WinDriver/KernelDriver samples, you will need to add the registration code yourself.

Note that after the initial registration of the license from the DriverWizard, your license string will automatically be activated with every session of the wizard. This is the reason that you have found that your code seems to work if you first run DriverWizard (since the license was already registered from the wizard, even though it was not explicitly registered from the code).

Please refer to the description of WDU_Init() (USB) / WDC_DriverOpen() (PCI/ISA) in the WinDriver User's Manual to learn how to correctly register your license registration string from the code.
If your codes uses the low-level WD_xxx APIs instead of the WDU or WDC APIs, use the function WD_License() to register your license string. (WD_License() is described in the WinDriver PCI Low-Level API Reference - WinDriver/docs/wdpci_lowlevel_api_ref.pdf - in v8.00 and above of WinDriver. In earlier versions the function is described in the WinDriver User's Manual, which is found under the WinDriver/docs/ directory for the specific version). [If you are using version 5.05b or earlier of WinDriver/KernelDriver, you can refer to the WinDriver/redist/register/register.txt or KernelDriver/redist/register/register.txt registration file (respectively) for relevant registration instructions].

Beginning with version 5.20 of WinDriver, the generated DriverWizard evaluation code already includes the required license registration code, but using a demo license string. When moving to a registered version you simply need to replace the demo license string that is used in the call to WDU_Init()/WDC_DriverOpen()/WD_License() in the evaluation code with your specific license registration string.

NOTE: Make sure that your code calls the license registration function before any other WinDriver API call (apart from WD_Open or WD_Version(), when using the low-level WD_xxx APIs).

I developed a driver with WinDriver, but it only runs on the development machine that I used to create the driver. How can I distribute the driver to other machines?
When installing WinDriver/KernelDriver, the only thing that will be locked to one machine is the development environment - i.e., the DriverWizard (unless you are using a floating WinDriver license, which enables you to use the DriverWizard on any PC). Once you have written and built your code, you may install and run it on any machine you want. The device driver you create using WinDriver/KernelDriver is yours to distribute in as many copies as you wish, royalties free, provided you do not distribute your own driver development kit (see the following FAQ: http://www.jungo.com/support/faq.html#MIP).
To find out how to distribute the driver you developed with WinDriver/KernelDriver, please review the Distributing Your Driver chapter in your WinDriver/KernelDriver User's Manual and the distribution technical documents for your WinDriver/KernelDriver version in the Licensing And Distribution section of the WinDriver/KernelDriver Technical Documents. Please note that before distributing your driver you must register your license registration string from the code, as explained in the manual and in the following FAQs: http://www.jungo.com/support/faq.html#reg1 and http://www.jungo.com/support/faq.html#lfc19.

Back to Top

What is the Debug Monitor utility? How do I start it? What is 'Trace' mode?
The Debug Monitor utility (a.k.a. Monitor Debug Messages - in previous versions) - wddebug_gui (graphical) or wddebug (non-graphical), found in the WinDriver/KernelDriver util/ directory - is an application program that logs detailed debugging information from the WinDriver kernel module.
For detailed information on this utlity and how to use it, refer to the WinDriver User's Manual and to the following Technical Documents: #12 (wddebug_gui - for Windows, Linux, and Solaris) or #13 and #14 (wddebug - for Windows CE, Linux, Solaris, and Windows [#13] and VxWorks [#14]).

NOTE: The Debug Monitor can also be run on target PCs on which the WinDriver module has been installed, even if the entire WinDriver/KernelDriver tool-kit was not installed on the target PC. This can be useful, for example, for debugging problems on your customers' PCs, as explained in the following FAQ: http://www.jungo.com/support/faq.html#lfc6009.

My application hangs the system, so I cannot see the debug information in the Debug Monitor log. Is there a way to save the debug information in case of a system hang/crash?
Yes. You can select to send the debug information from the Debug Monitor to a kernel debugger, as explained in Technical Document #44.
On Windows, in order to save the debug information in case of a hang/crash, you will need to install the kernel debugger on another PC and establish a debug session between this PC and your development PC. For more information on what to do in case of a crash on Windows, refer to Technical Document #121.
On Linux you will find the debug log, after reboot, in /var/log/messages.

How do I implement an accurate timer using WinDriver?
WinDriver provides an API for accurate sleep times (in 1 microseconds resolution) - WD_Sleep().

By default, WD_Sleep() performs a busy sleep.

If you need to perform a non-busy sleep:

• If a resolution of ~17,000 microseconds is sufficient for you, then you can either set up the SLEEP_NON_BUSY flag in the dwOptions field of the WD_SLEEP structure, which is passed to WD_Sleep(), in order to perform a non-busy sleep; Or use the standard OS sleep functions (e.g., Sleep(), WaitForSingleObject(), etc.). Using WD_Sleep() will maintain your code's portability, as opposed to the standard OS sleep functions.
  
  
• If you need a higher resolution, you can write a Kernel PlugIn application, using the Virtual Timer Device (VTD) API in Win95. The problem is that the code that will execute on the timer is kernel mode code. You will have to write code to transfer the data from user mode to kernel mode, and then transfer the results back from kernel mode to user mode.

Can I debug code easily using MSDEV / MS Visual C++?
YES! The code of the device driver you write runs in normal Win32 user mode. Therefore, you can compile and debug your code using MSDEV/MSVC++.
Please refer to Technical Document #19 for more information regarding debugging your driver code with WinDriver and KernelDriver.

I need to define more than 20 'hardware items' (I/O, memory and interrupts) for my ISA card. Therefore, I increased the value of WD_CARD_ITEMS in the windrvr.h header file (due to the definition of the Item member of the WD_CARD structure as an array of WD_CARD_ITEMS WD_ITEMS structures). But now WD_CardRegister() will not work. Why?
If you need to define more than WD_CARD_ITEMS items for your card (currently 20 items, according to the definition of WD_CARD_ITEMS in windrvr.h), do not modify the value of WD_CARD_ITEMS in the code, but instead, simply call WD_CardRegister() several times from your code, with different items each time. [It is not mandatory to lock all the resources on a specific card with a single WD_CardRegister() call]. Alternatively, consider grouping several memory/IO address ranges into a single BAR definition, so that the overall resources item count does not exceed the default 20 items limit.

Please do not change anything in windrvr.h. The affect will certainly not be what you expect and it could be potentially disastrous.

I installed the registered version of WinDriver. Now my sample programs, which are supplied by Jungo (PCI Bus Diagnostics, Parallel Port Sample, etc.), do not work. What is the problem?
The sample programs were written with the evaluation version in mind (so that they can be distributed and used without a license during the evaluation period). You can modify their source code in order to register your license registration string from the code - as explained in the following FAQ: http://www.jungo.com/support/faq.html#reg1.

My WD_Transfer() memory transfer routines are too slow. Can I speed them up?
You can replace the calls to WD_Transfer() with direct memory access, by utilizing the virtual user mode mapping of the base physical address for the relevant memory range, which is returned by WD_CardRegister() in:
cardReg.Card.Item[i].I.Mem.dwUserDirectAddress
(where 'i' is the index number of the memory base address in the WD_ITEMS 'Item' array).
This is documented in the WinDriver User's Manual (see the description of WD_CardRegister() in the "Function Reference" chapter and the "Improving Performance" chapter) and in Technical Documents #74 and #17. Technical document #17 also includes other suggestions on how you might improve your driver's performance with WinDriver.

Can WinDriver be used to write a driver for multimedia, specifically a MIDI driver?
Yes! A midi driver is a DRV file (which is actually just a standard DLL). The calls to access the hardware (I/O, memory and interrupts) can be performed with WinDriver.

Generally, a MIDI driver consists of two parts: The first is a user mode DRV file, which has an exported API that Microsoft defined for MIDI drivers. The second is a kernel mode SYS (WinNT/2K/XP) or VxD (Win95/98) file to access the hardware. The DRV user mode file calls the SYS/VxD kernel mode to perform the hardware access.

WinDriver will save you the need to implement the second part. You will not need to create a kernel mode driver. You can use the ready-made windrvr6.sys kernel driver (or windrvr.sys/vxd in earlier versions), which implements WinDriver's API. All you need to write is the user mode DRV file. This will enable you to write and debug your driver entirely in the user mode.

I have installed my driver on a target machine and there are some problems that don't occur on my development machine. Can I run the Debug Monitor utility run on a target machine as well, or only on the development machine?
WinDriver's (and KernelDriver's) Debug Monitor utility can run on any machine (unlike the WinDriver DriverWizard utility, which is locked down to the development machine). Therefore, you can simply copy the wddebug_gui file (or wddebug - For non-graphical platforms) from the WinDriver/util directory on the development machine, to the target machine, and run it. For detailed information regarding the Debug Monitor utility, refer to the WinDriver User's Manual and to the following FAQ and Technical Document: http://www.jungo.com/support/faq.html#lfc1, Technical Document #12.

no need to refer to these TDs explictly in this context.">

Back to Top

Is the Kernel PlugIn free? How do I obtain a license to use it?
The Kernel PlugIn is an integral part of the WinDriver PCI/ISA tool-kit.
No additional license or payment is required in order to use it.

Do I need Microsoft's DDK to build a Kernel PlugIn project?
If you are using Kernel PlugIn to develop a SYS driver for Windows Server 2003/XP/2k/NT or Windows Me/98, you need to install Microsoft's DDK for your target OS in order to successfully build your Kernel PlugIn driver.
For more information regarding Microsoft's DDK library, refer to: http://www.microsoft.com/ddk/.
[Note that when using the DDK to build your Kernel PlugIn driver, you will also need to set the BASEDIR or DDKROOT environment variable to the location of your DDK library, as explained in the WinDriver User's Manual.]

Development of VxD Kernel PlugIn drivers, which was supported for Windows98/Me in earlier verisons of WinDriver (v6.0x-), does not require you to install Microsoft's DDK in order to successfully build the driver, unless you choose to add your own DDK function calls to your Kernel PlugIn application. (Note that using OS-specific DDK functions can damage the driver's portability).

How many interrupts can we expect to service in one second (typical)?
Using WinDriver's Kernel PlugIn feature, you can expect to handle more than 100,000 interrupts per second, without missing any of them.
For sample Kernel PlugIn interrupt handling code, use the DriverWizard to generate code for your device (for PCI and PCMCIA devices, define the data for clearing the interrupt in the wizard before generating the code), or take a look at the WinDriver Kernel PlugIn sample code - KP_PCI (WinDriver/samples/pci_diag/kp_pci/ - v7.00+) or KPTEST (WinDriver\kerplug\kptest\kermode/ - v6.23-a).

In the user mode you can handle around 5,000-10,000 interrupts per second, but since Windows is not a Real Time OS, you might miss some of the interrupts once in a while (although WinDriver tells you when you have missed an interrupt and how many interrupts were missed).

For an explanation regarding interrupt latency with WinDriver, refer to Technical Document #48.

Is the driver code always locked into physical memory?
Yes.

How do I allocate locked memory in the kernel, which can be used from within the Kernel PlugIn interrupt routines?
WinDriver implements malloc() and free() for kernel mode memory allocation (see Technical Document #34). Since the allocated memory is locked, you can also use this memory in your Kernel PlugIn interrupt routines.
You can also share a memory buffer between the user mode and Kernel PlugIn applications - as explained in Technical Document #41.

When handling my interrupts entirely in the Kernel PlugIn, can I erase the interrupt handler in the user mode?
Yes - You can erase the user mode interrupt handler routine.
You can also implement some of the interrupt handling in the Kernel PlugIn and some of it in the user mode. The return value of KP_IntAtDpc() (which is called when the high-priority KP_IntIrql() routine returns TRUE) determines the number of times that the user mode interrupt handler routine will be executed (if at all).

Can I use the Kernel PlugIn feature to write a SYS driver file?
Kernel PlugIn enables you to create an add-on *.sys/.o/.ko (and in earlier versions of WinDriver also *.vxd) kernel driver (depending on your OS) to extend the features of WinDriver for your needs. The Kernel PlugIn driver your create is not stand alone - it can only work together with a user-mode driver that activates it.

Note that when using WinDriver's Kernel PlugIn feature, you must also install the windrvr6/.sys/.vxd/.o/.ko or windrvr/.sys/.vxd/.o driver module - depending on the the target OS and your WinDriver version.

How can I print debug statements from the Kernel PlugIn that I can view using a kernel debugger, such as WinDbg?
You can use WinDriver's WD_DebugAdd() API (available from v5.03 and above) in order to print debug messages from your Kernel PlugIn (or user mode) code to the Debug Monitor utility, and then view the messages in the Debug Monitor log. WD_DebugAdd() can be called from within any user-mode or Kernel PlugIn function, including KP_IntAtIrql().

You can select to send the debug information from WinDriver's Debug Monitor to a kernel debugger, as explained in Technical Document #44.

You can also add calls in your Kernel PlugIn to OS kernel functions that print directly to the kernel debugger, for example:
KdPrint() - on Windows Vista/Server 2003/XP/2k/NT
DbgPrint() - on Windows Vista/Server 2003/XP/2k/NT/98/Me
printk() - on Linux
cmn_err() - on Solaris

My PC hangs while closing my application. The code fails in WD_IntDisable(). Why is this happening? I am using the Kernel PlugIn to handle interrupts.
This might happen if you are enabling the interrupt from your Kernel PlugIn interrupt routines, and simultaneously disabling it from the user mode (using WD_IntDisable() or InterruptEnable() / WDC_IntEnable() - which call WD_IntDisable()). Since the interrupt is active (having been enabled from the Kernel PlugIn), the interrupt cannot be disabled and the PC hangs waiting for WD_IntDisable() to return.

A possible solution, is to call WD_IntDisable()/InterruptEnable()/WDC_IntEnable() as an atomic operation, so that it will disable the interrupts successfully before the Kernel PlugIn interrupt routine enables the interrupt.

When I install my Kernel PlugIn module I get errors regarding unresolved symbols.
Please refer to http://www.jungo.com/faq.html#kplinux under the Linux Issues section for the answer to this question.

If I write a new function in my SYS Kernel PlugIn driver, must it also be declared with __cdecl?
No. Only the callbacks used by WinDriver need to be declared as __cdecl.

Back to Top

What is A WDM device driver and does WinDriver support WDM?
When writing device drivers, developers must write a separate device driver for the Win 9x and the Win NTx kernels. Microsoft has developed a cross-platform operating system support for input devices, in order to provide a uniform way for code to access such devices across Windows Vista, Server 2003, XP, 2000, 98, and Me platforms. This new support is known as Windows Driver Model or "WDM". WDM is based on the original Windows NT driver model, with modifications to support Plug-and-Play and power management, and is used for most multimedia device types and many other newer device types, such as USB and 1394 devices.
Beginning with version 5.20 of WinDriver, WinDriver's kernel module - (windrvr6.sys / windrvr.sys in v5.22-) - which implements WinDriver's API, is a full WDM driver.

When installing a WinDriver-based driver on a Windows XP machine, Windows reports:
  The software you are installing for this hardware has not
  passed Windows Logo Testing ... and may impair or destabilize
  the correct operation of your system ...
Is this a problem? How to avoid such messages?
This message is not actually an error message and is not an indication of any problem in the installation process or with the driver. This message is issued by Microsoft's Windows XP to indicate that the driver was not tested and digitally signed by Microsoft's Windows Hardware Quality Labs (WHQL).

To avoid this message you can contact Microsoft in order to get your driver digitally signed. For more information Click Here.

Is WinDriver digitally signed by Microsoft?
How can I digitally sign my WinDriver-based driver?
WinDriver is fully WHQL-compliant. The driver you develop with WinDriver for Windows can be submitted to Microsoft's Windows Hardware Quality Labs (WHQL) testing in order to digitally sign the driver with Microsoft. Several WinDriver customers have already successfully signed their WinDriver-based drivers with Microsoft.
For more information on Microsoft's WHQL testing and how to get a WHQL certification for your hardware and WinDriver-based driver, refer to to the "WHQL Certification" section in the WinDriver User's Manaul and to Microsoft's documentation, for example: http://www.microsoft.com/whdc/whql/default.mspx/.
For further assistance, contact support@jungo.com.

Back to Top

Do you have a debug utility for Windows CE?
Yes - The Debug Monitor utility is also available on Windows CE.
Please refer to Technical Document #13 for more information.

I am writing a CE NDIS driver. It will talk to the CE IP stack.
I need to access the NIC hardware from my driver. Can I use WinDriver?
Yes. In Windows CE, device drivers, including NDIS drivers, are DLLs. So a NDIS network driver can use the WinDriver CE API to talk to the hardware.

I am writing a serial port to NDIS driver for Windows CE. Can I use WinDriver?
Yes. In Windows CE, device drivers, including NDIS drivers, are DLLs. So a NDIS network driver can use the WinDriver CE API to talk to the hardware.

Back to Top

When I install my Kernel PlugIn module I get errors regarding unresolved symbols.
Make sure to install the WinDriver kernel module - windrvr6.o/.ko (or windrvr.o - in v5.22 or below) - before installing your Kernel PlugIn module, since the Kernel PlugIn driver depends on the WinDriver driver module for its operation.
For detailed Kernel PlugIn installation instructions, refer to the WinDriver User's Manual for your WinDriver version and to Technical Document #62.

I am trying to allocate a kernel buffer on Linux. I can allocate a 100KB buffer, but I cannot allocate 150KB. What should I do?
This is a limitation in Linux kernels - by default you can allocate a maximum of 128KB for kernel buffer allocation. However, it is possible to recompile the kernel to get larger sizes and there is also a path that enables this - as explained in Technical Document #64.

Back to Top

Do you have a debug utility for Driver Builder on VxWorks?.
Yes - you can use the Debug Monitor utility for VxWorks - wddebug.out - As explained in Technical Document #14.

I have followed the DriverBuilder installation instructions in your documentation, but when I try the pci_diag_main, it says that the following symbols are unresolved: PCI_ReadPCIReg, PCI_WritePCIReg, PCI_DetectCardElements ...
These are utility functions included in the DriverBuilder's sample PCI library. You may have missed adding some C files to your project. Read the source file pci_lib.c (or pci_diag_lib.c) and check if it should be included in your project.

Can I use DriverBuilder to write a BSP (Board Support Package)?
No, DriverBuilder is designed for writing device drivers. It cannot be used to develop a Board Support Package (BSP).

Back to Top

I downloaded an FPGA configuration file to the board, using Altera's Byte Blaster cable. I ran the WinDriver Altera diagnostic program, but it failed to find any of the expected Altera items. When I downloaded my PCI core to the FPGA and rebooted the OS, the BARs came up zeroed. The OS also failed to hook my interrupt.
There are a number of possible causes for this:

• The Altera core gives you the opportunity to hardwire the BARs to an address. This means you would be assigning address space for your PCI functions manually. BARs should be hardwired to 0x00000000 and the hardwire BAR enable bits 5:0 of the enable bits parameter should also be set to zero if you are using a target PCI core. This will disable any hardwiring of BARs by the core. Altera says that the BAR hardwiring is used if you are using a Master-Target Core.
  
  
• The Altera core also gives the capability of enabling an expansion ROM - for example, the Altera PCI Development board that uses the pci_t32 (PCI target 32 bit Core). The core defaults to enabling the expansion ROM even though the board does not have an expansion ROM. The OS uses the expansion ROM to execute boot code. In order to disable the expansion ROM you may have to set the expansion ROM BAR to 0x00000000 and set bit 7 of the enable bits parameter (expansion ROM enable) to zero.

Back to Top

 

Does WinDriver support a laptop's CardBus slot using the PCI driver?
Yes. You can use the WinDriver PCI tool-kit and API to develop a CardBus driver, as explained in Technical Document #94.

Note that on Plug-and-Play (PnP) operating systems, you need to generate and install an INF file for your device in order to successfully handle it with WinDriver (you can use the DriverWizard to generate the INF file, as explained in the WinDriver documentation). The INF file will register your device to work with WinDriver's kernel driver (windrvr6.sys, or windrvr.sys - in v5.2X / wdpnp.sys/wdusb.sys - in previous versions).

Back to Top

I am using WinDriver for communicating peripherals with the parallel port. In case of ECP mode, some computers work well, but on one computer this does not work.
This might be a hardware problem, due to BIOS-specific implementations of parallel port modes on various computers. WinDriver cannot control this behavior, since it is programmed into the BIOS. We advise you to follow the brand of computer or BIOS that you have observed works correctly.

Back to Top

I am currently seeing 25ms between an interrupt and activation of our user-mode interrupt handler. Is this the performance that I should expect with the handler in the application? I am considering moving our interrupt handler to a Kernel PlugIn to enable us to handle interrupts faster.
The user-mode interrups handler can service up to 10,000 interrupts per second (although we cannot commit to a specific number, since this is dependant upon many factors). A latency of approximately 25ms should generally not happen, but it can from time to time. Using WinDriver's Kernel PlugIn feature will ensure that this will not happen. However, nothing can protect against some badly written device drivers that sometimes disable interrupts for long periods. Such offending drivers should be identified and upgraded or removed. For more information regarding WinDriver's interrupt latency, see Technical Document #48

I used the DriverWizard to generate code to handle my level sensitive interrupt. After WD_IntWait() returns, I read the interrupt status register but it does not show me that an interrupt had occurred. This is a problem if I have multiple cards sharing an interrupt.
When a PCI interrupt occurs, WinDriver writes/reads the interrupt status register in order to clear (acknowledge) the level sensitive interrupt. This is performed directly in the kernel, according to the information that was set up in the code, beforehand, when enabling the interrupt. To read and save the value of the interrupt register before the interrupt is cleared, so that you can later reference this value from within your interrupt handler routine, you need to set up a relevant read command in the interrupt transfer commands that are set up in the dwCmd field of the WD_INTERRUPT structure, which is passed to InterruptEnable() (/InterruptThreadEnable() in earlier versions)/WD_IntEnable(), and set the INTERRUPT_CMD_COPY flag in the dwOptions field of the WD_INTERRUPT structure (int.dwOptions |= INTERRUPT_CMD_COPY).
This is documented in the "Interrupt Handling" section of the WinDriver User's Manual and in Technical Documents #104 and #75.

I tried to use the DriverWizard to listen to the interrupts of my PCI board, but I got the following message:
  WARNING!! You did not choose an Access Register
  for this level sensitive interrupt.
  If you do not want to specify a register you will
  have to manually change the code generated by
  DriverWizard.
PCI uses level sensitive interrupts, which must be acknowledged and cleared in the kernel immediately when they are received. Therefore, WinDriver requires you to define an interrupt status register, which should be read/written in order to clear the interrupt. This is a precautionary feature, because a level sensitive interrupt that is not acknowledged can hang your PC. Please refer to Technical Document #105 for a detailed explanation on how to listen to PCI interrupts with WinDriver's DriverWizard. Please also refer to Technical Document #75 and to the WinDriver User's Manual for a general explanation regarding the handling of PCI interrupts with WinDriver.

NOTE that as specified in the WinDriver documentation, in order to handle PCI interrupts correctly with WinDriver on Plug-and-Play (PnP) operating systems (Windows Vista/Server 2003/XP/2000/98/Me), you must first install an INF file for the device, which registers it to work with WinDriver's PnP driver (windrvr6.sys; In previous versions - windrvr.sys/wdpnp.sys/wdusb.sys, depending on the version).

Does WinDriver support Message-Signaled Interrupts (MSI)?
Yes. Beginning with version 9.10 WinDriver supports Message Signaled-Interrupts (MSI) and Enhanced Message-Signaled Interrupts (MSI-X) on Windows Vista and Linux.
Support for additional operating systems will be added in future versions of Windriver.

NOTE: Support for MSI/MSI-X on Windows is provided only on Windows Vista because earlier versions of Windows do not support these types of interrupt.

For more information on WinDriver's MSI/MSI-X support, refer to the WinDriver User's Manual.

Back to Top

I am unable to lock a large memory block (more than 1MB) using WD_DMALock(). The Debug Monitor shows that Scatter/Gather lock failed.
To lock a large DMA buffer (more than 1MB), when using Scatter/Gather DMA (i.e., dwOptions is not set to KERNEL_BUFFER_ALLOC for Contiguous Buffer DMA), please follow these steps:

1. Set the DMA_LARGE_BUFFER flag in the dwOptions field of the WD_DMA structure. [This flag is only required when performing Scatter/Gather DMA, as opposed to Contiguous Buffer DMA].
   
   
2. Calculate the number of pages you need to lock, in the following manner, and assign it to the dwPages field of the WD_DMA structure:
   
   dwPagesNeeded = transferCount / 4096 + 2;
   
   where transferCount is the number of bytes that you want to lock.
   
   
3. NOTE: By default the WD_DMA structure can hold information of up to 256 pages (= WD_DMA_PAGES, defined in WinDriver\include\windrvr.h). If you wish to lock more than 256 pages, you need to have enough memory to hold the information of all the pages. To allocate enough memory to hold the information (address and number of bytes) of the additional pages required, you can do the following:
   
   WD_DMA *pDma;
   pDma = (WD_DMA *)malloc(sizeof(WD_DMA) +
       sizeof(WD_DMA_PAGE)*(dwPagesNeeded -
       WD_DMA_PAGES));
   

If the memory allocation still fails, verify that there are sufficient system resources for the attempted memory allocation (both in the kernel and in the user mode address space, to which the memory is mapped).
On Windows, you may need to increase the size of the non-paged pool (from which the memory is allocated), as explained in Technical Document #58. If you still cannot lock the entire buffer, try locking a smaller buffer.

For more information regarding performing DMA with WinDriver, please see the section regarding "Performing DMA" in the "WinDriver Implementations Issues" chapter of the WinDriver User's Manual and to the description of the WinDriver DMA APIs in the "Function Reference" chapter of the manual.

I have locked a memory buffer for DMA on Windows 2k. Now, when I access this memory directly, using the user mode pointer, it seems to be 5 times slower than accessing a "regular" memory buffer, allocated with malloc(). Why?
"Regular" memory (stack, heap, etc.) is cached by the operating system. When using WD_DMALock(), the data is non-cached, in order to make it DMA safe. Therefore, the memory access is slower.
Note that this is the correct behavior for DMA.

Beginning with version 5.21 of WinDriver, when performing Contiguous Buffer DMA on Windows Vista/Server 2003/XP/2000/NT, you can set the DMA_ALLOW_CACHE flag in the dwOptions field of the WD_DMA structure that is passed to WD_DMALock(), in order to allocate a cached DMA buffer. When using this flag, specify whether you wish to write to the device or read from the device, using DMA_READ_FROM_DEVICE or DMA_WRITE_TO_DEVICE

If you have allocated the memory in the user mode, and then passed its address to WD_DMALock() - i.e., if you performed Scatter/Gather DMA - then calling WD_DMAUnlock() will unlock the memory buffer and it will now function like other "regular" memory in terms of access speed.

Back to Top