This is my first Windows device driver and I have been assigned a task to develop a Windows device driver from scratch. When the user installs this driver on a windows PC it would ask the user, during the installation process, to enter the number of virtual serial port that user requires & after installation of the driver the number of virtual port desired by the user shall be created. Then the user connects his customized printer to the windows PC via USB port. The user should be able to send data to the printer through the Hyper terminal by selecting any of the newly created Virtual serial port at 9600 baud rate, 8 data bit, No parity and 1 stop bit.
Now to get started I am using a windows 7 system on which I have installed Visual Studio 2015 along with Windows Driver Kit 10 form the MSDN website. I have also downloaded the Windows drivers sample codes form the GITHUB this sample soce base contains a virtualSerial UMDF project under serial/Svirtualserial2. This project file contained 2 projects one being the Virtualserial2 project and the other is a FakeModem project so I deleted the FakeModem project (as its was of no use for me) and successfully compiled the source/VirtualSerial2 sample code. after compilation a .dll (as UDMF drivers have .dll extensions) file gets generated in the debug folded but I don't get any .exe for this driver so I am not sure how can I install this driver on my system.
I was also going through this link https://msdn.microsoft.com/en-in/library/windows/hardware/dn745911%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 that list the process to debug a UMDF driver using WinDbg, in an example it also asks us to run the .exe so my first question is how do I need to generate a .exe file of my driver & test it on a system.
Along with this I have one more query. after I install my driver on the target system (Windows 7 32 bit I need to link it to the hyper terminal). So that I will be able to send the Commands & data to my printer through the hyper terminal and my driver will be responsible to take the data from the hyper terminal and send it to my printer through USB. How can I do that?
Am I going in the right direction?
I have application on windows server 2008 which gets request for connection via web. The connection is made through registry key. I get this error "The description for Event ID 9300 from source CUSTOMPROJECT Security 3335 cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
ActiveX component can't create object
the message resource is present but the message is not found in the string/message table"
I would like to know is there a 64 bit version of advapi32.dll ?
On a 32-bit computer, all 32-bit programs store their files in C:\Program Files, and the system-wide library location is C:\System32.
On a 64-bit computer, 64-bit programs store their files in C:\Program Files, and the system-wide C:\Windows\System32 folder contains 64-bit libraries. 32-bit programs store their files in C:\Program Files (x86), and the system-wide folder is C:\Windows\SysWOW64.
The “WOW64” part of the name here refers to Microsoft’s “Windows 32-bit on Windows 64-bit” software, which is a part of the operating system. This allows Windows to run 32-bit programs on a 64-bit version of Windows. WoW64 redirects file access to ensure programs will work properly.
Here is a good article explaining it.
A quick google for advapi64.dll returns a fair number of results.
I also found this link:
http://social.msdn.microsoft.com/Forums/sk/netfx64bit/thread/410374d5-139a-47f9-9d5b-3851247f4024
Which indicates you should look for the 64-bit version of the file here:
%WinDir%\System32
I've download the current version of DummyNet and according to readme I'm following these steps:
Windows: INSTALL THE NDIS DRIVER
open the configuration panel for the network card in use
(right click on the icon on the SYSTRAY, or go to
Control Panel -> Network and select one card)
click on Properties->Install->Service->Add
click on 'Driver Disk' and select 'netipfw.inf' in this folder
select 'ipfw+dummynet' which is the only service you should see
click accept on the warnings for the installation of an unknown
driver (roughly twice per existing network card)
But when I select 'netipfw.inf' and click OK the system return an error (unable to find any drivers for this device).
Note that I've previously disabled the check control for digital signature typing on Start->Exec the following command:
bcdedit /set nointegritychecks ON
and reeboting the system.
I need to be able to solve this issue because when I try to execute some dummynet command the system returns:
my_socket failed 2, cannot talk to kernel module
ipfw: socket
My network card is a NVIDIA nForce integrated on my mother board Asus Striker II.
Have you any idea to solve the problem? Thanks.
I was able to get this working using Windows 7 x64.
Download DummyNet.
Move the files from ipfw3-2012\binary64 to ipfw3-2012\binary, choose
Move and Replace
Install the driver using instruction in ipfw3-2012\binary\README.txt.
Note I had to reboot with Disable Driver Signature Enforcement as detailed
here before I could install the driver. Should look like this
Dummynet is a 32bit NDIS driver, if you look through the source at: http://info.iet.unipi.it/~luigi/dummynet you can see that the ipfw folder only has exports from ws2_32.dll
You would need to port the driver to x64 to get it to work.
Try running the command prompt as Administrator. For example, open the start menu, find command prompt, right click it and hit "run as administrator" this is likely your issue. It is similar to trying to run this on MacOS and not using the "sudo" command. If this doesn't solve your problem I would be concerned that it was because you are on 64bit and I don't believe Dummynet is compatible on that architecture yet.
I'm dealing with an issue that has arisen for an application I've been working on which connects to a Access file via JDBC-ODBC. On other Windows platforms, this issue hasn't been encountered, but on Windows 7 64-bit boxes, attempting to connect with DSN-less connection strings return:
java.sql.SQLException: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
Multiple variations on the string have been attempted, but all of them have returned the same error. Here's how it currently tries to connect:
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
StringBuffer databaseConnectionString;
if (SystemUtils.IS_OS_WINDOWS_7) {
databaseConnectionString = new StringBuffer("jdbc:odbc:DRIVER=Microsoft Access Driver (*.mdb, *.accdb);DBQ=");
databaseConnectionString.append(databaseFile);
} else {
databaseConnectionString = new StringBuffer("jdbc:odbc:Driver={Microsoft Access Driver (*.mdb)};DBQ=");
databaseConnectionString.append(databaseFile);
databaseConnectionString.append(";DriverID=22;READONLY=false}");
}
Examining the driver in the 32-bit ODBC Data Source Admin confirms that the drivers are present. However, when regedt32.exe is used to examine ODBC drivers (HKEY_LOCAL_MACHINE/SOFTWARE/ODBC/ODBCINST.INI/ODBC Drivers), none of them appear.
Can anyone help to shed some light on this?
I found the problem was that I was running the program in 64-bit Java. Although I have yet to successfully have the program detect if it's running in 32-bit or 64-bit Java, I have solved the solution by installing a 32-bit Java runtime environment and using a .bat file that reads as follows:
#echo off
"C:\Program Files (x86)\Java\jre6\bin\java" -D32 -Xmx1024m -jar programName.jar
Thanks for the help!
This was a difficult challenge given the paucity of meaningful error messages from JAVA or MS's ODBC driver. The answers above about down selecting to 32bit Java and MS Access drivers (using AccessDatabaseEngine.exe from MS) did work but cost a significant penalty (about 30%) in processing other actions compared to using 64bit Java. I was unwilling to pay this price so I installed 64bit Java (in conjunction with 32bit, both in a separate directory c:\Java\32 or 64). This latter directory issue was important for me since I was using Apache Geronimo and it would not start if Java was installed in Program Files (x86)... as the (x86) seemed to kill its batch file parsing. I then uninstalled 32bit MS Access and installed 64bit MS Access (AccessDatabaseEngine_x64.exe). Finally, it worked with both higher speed and MDB connection.
When I try to connect to local ports, Computer -> Connect local, using Portmon v. 3.02, I'm getting an error message, Error 2, in a small error dialog box:
I run the tool as an administrator (if not, I get error 6).
By the way this is a Windows 7 x64. On 32-bit, in Windows 7 x86, it works fine. How can I fix this problem?
Sysinternals' Portmon works only on 32-bit versions of Windows. It does not support 64-bit (probably its driver is not signed).
From the Portmon homepage:
Runs on:
Client: Windows XP (32-bit) and higher (32-bit).
Server: Windows Server 2003 (32-bit) and higher (32-bit).
In Windows Explorer, right click on portmon.exe --> select Properties --> click the Compatibility tab, and Run in Windows XP compatibility mode. It works fine like that in Windows 7 64-bit.
"Error 2" is "Cannot find the file specified", that is, cannot find a required DLL file.
Originally, you got this error when you tried to run Portmon from a network location: that broke the security trust, causing Portmon to be untrusted (or perhaps just messing up the search path somehow).
On my copy of Windows 7 64 bit, Microsoft Dependency Walker (depends.exe) tells me that PORTMSYS.SYS (the file created/loaded by Portmon.exe), has unresolved dependencies on ci.dll, clfs.sys, hal.dll and kdcom.dll.
Those are the
code integrity
common log file system
hardware abstraction layer
kernel debugger com
libraries, and they aren't actually missing: if they were, Windows wouldn't boot. However, I don't see a copy of those files in SysWow64. This suggests to me that the problem is not with portman.sys: the problem is with the win32 compatibility layer in Windows 7/64 bit: It doesn't support debug properly.
It is now 2018. There is no 64-bit version of Portmon. Serial ports are a legacy standard. The Windows 7 problem was fixed by the release of Windows 8.1. However, there is a faint chance that some Visual Studio utility or security update back-ported to Windows 7 will fix the problem. Perhaps someone who is familiar with SysWow and debugging will comment.
Instead of portmon for Windows x64, you can use an emulator of a pair of virtual COM ports and a simple program that will connect the physical port and one of the virtual ones, as well as perform the logging function.
To create a pair of virtual COM ports you can use:
com0com (preferably version "com0com-2.2.2.0-x64-fre-signed", because it contains signed x64 driver)
Virtual Serial Ports Emulator (VSPE), every time it starts on x64 it asks to purchase a driver, but it works even if you refuse.
Simple mapping and logging program can be found e.g. here or you can write it yourself, it is simple.
The sequence of actions is follows:
Сreate a pair of virtual COM ports using emulator (for example, COM28 and COM29)
Let the external device be connected to the computer COM1 port. In the program, whose exchange with external device we want to listen to, we set up a port COM28 (instead of СОМ1) for communication.
In the mapping program, we set up that we want to bind and log ports COM1 and COM29 (don't forget to set the port baud rate).
I haven't tried it yet, but this question mentions com0com. It creates two virtual serial ports and emulates a null modem cable between them. It claims to be able to run on 64 bit Windows. I'm not sure whether it comes with software that lets you just pipe input from a real port into one of the virtual ports. One of the FAQ's says that you can turn on logging.
I guess in the worst case, you could write your own small program that pipes data from a real port to one of the virtual ports and logs it all.
There's also this question on open-source alternatives that mentions a couple of projects.
I've used AccessPort
http://sudt.com/en/ap/download.htm and it works great. Very similar to Portmon
Don't start Portmon from a network drive/path or something else.
Copy on to the hard disk drive, e.g. on the desktop, restart and try again!
If you run Portmon in compatibility mode, it will work.
Check Make older programs run in this version of Windows.
It says:
To run the Program Compatibility troubleshooter:
Open the Program Compatibility troubleshooter by clicking the Start button Picture of the Start button, and then clicking Control Panel. In the search box, type troubleshooter, and then click Troubleshooting. Under Programs, click Run programs made for previous versions of Windows.
Follow the instructions in the troubleshooter.
The above is a public explanation from Microsoft for a common situation when running older applications in Windows.
But, I can say it briefly;
Right click on portmon.exe
Select menu about "troubleshooting compatibility problem" or something like that (I'm using a foreign version of Windows, so I don't see correct name of that menu in English.)
Select automatic mode
It will detect the problem and recommend Windows XP (SP2) mode
Select it and execute Portmon again.
I hope it works!
Instead of Portmon you can also use the IO Ninja program with the "Serial Monitor" plugin.
It gives a little less information than Portmon, but in a more understandable form. The main thing is, just like a Portmon, it allows you to see the data that is transmitted between a third-party application and an external device via a serial port. The program works under modern versions of Windows (I tried it myself on Windows 10 x64). The aforementioned plugin "Serial Monitor" is paid (but has an evaluation period).
Note: the port that you want to monitor must first be connected to the "IO Ninja" program, and then opened in a third-party application whose exchange with an external device you want to track.
Just to test that the hardware is working, you could perhaps boot a Linux live CD and run the statserial and/or minicom program to verify that it works. The Knoppix distribution seems to contain both those programs.
Serial ports on Linux are named /dev/ttyS0 for COM1, /dev/ttyS1 for COM2, etc.