I'm attempting to build/install a "custom" KMDF driver (really it’s just the KMDF template in Visual Studio as is). My goal is to take a PCIe device in the device manager and update its driver to my new custom driver.
I build the KMDF template, generate an *.inf, right click and install, and I get a message saying that the operation completed.
I then go to Device Manager, right click my PCIe card, Update Driver, Browse for Drivers, Let me pick from a list, show all devices, and at this point I would expect to see "Your Manufacturer Name" in the list, but I don't. I tried changing the "ManufacturerName" in my *.inf file in Visual Studio to a unique name, but I still don't see it in the list.
Also, I'm not seeing any relevant driver information with "driverquery /V"
What do I need to do to make my custom driver appear in the list such that I can "assign" it to the hardware device?
I think the problem was that I had my configuration build set to x86 instead of x64, and I'm on an x64 machine. I changed it, and now it's working.
Related
I am trying to get a connection to work on my machine to an AS400 database as per this link.
I have confirmed that there is no firewall blocking the machine I am working on. I have confirmed that the connection info works on a different machine with a .UDL file. I have installed the requisite C++ runtime libraries onto the machine and confirmed it has the appropriate .NET framework (it has 4.7.2). When I try to run the UDL file with the same connection information, I get "Provider cannot be found. Ensure that the provider has been installed properly." As far as I can tell I did, but it is not detecting that?
Can someone help me understand how to get it set up so that the UDL file will indicate if the connection was successful or not? I'm not really sure what is at issue at this point.
edit: I got lucky on more searching and so on further inspection, I can see that it is not in the registry editor. Could that be the issue? How would I add it there properly so that it shows up as a Data Link so that I can configure it correctly?
go here to download and install access client solutions
after installing the base package, navigate in the install folder and find the Windows_Application folder. In that folder, double click on install_acs_64.js. That will install the ODBC drivers.
run the ODBC Data Source Adminstrator app on the windows PC. Click the Add button. Select the IBM i Access ODBC Driver. Make sure to click the Server tab and set the default schema and library list.
Once the ODBC driver is installed you can test the connection by opening Excel and use the Data tab to config a connection to the IBM i database.
Problem summary
I'm attempting to establish a connection between HoloLens and an Android device, which worked sporadically in the beta-version of the MRTK.
However since moving to the MRTK RC1 (Also Refresh), I've encountered issues regarding the QR-scanning. When pressing connect, the two devices seemingly finds eachother, however when the wearer of the HoloLens1 looks directly into the QR-code, nothing happens. (the white dot and "Locating marker..." text is showing)
Background summary
1. The Setup:
Implemented working MRTK RC1 Refresh
Cloned Feature-SpectatorView separately, copying only the "MixedRealityToolkit.Extensions" folder to the MRTK project.
"Spectator View - HoloLens" prefab added to scene.
First pressing "HoloLens" in the PlatformSwitcher, building for HoloLens1, then switching to "Android" and exporting the project to Android Studio.
Building the .apk from Android Studio
(opencv binaries are downloaded and implemented since beta version, I haven't since changed them from when they worked the last time.)
2. The Proces:
On the HoloLens, I press the "Connect" button in which a white text appears saying "Locating Marker..."
The Android phone presses connect and it goes to "Waiting for User" then as soon as a HoloLens is connected, it switches immediately to a QR code that should be readible from said HoloLens.
Looking directly at the QR-code and nothing new happens, connection does not establish further.
I checked if something was not ticked in Player Settings/Capabilities, but I can't seem to find what the culprit would be. Did I forget something in this proces?
There are a few things that could be causing this issue.
If the Android device is showing a marker, this means the two devices have established a network connection and are communicating with one another. Typically, when I run spectator view I enable the following capabilities: "Internet (Client & Server), Internet (Client), Microphone, Pictures Library, Private Networks (Client & Server), Spatial Perception, Videos Library, Webcam" in the Package.appxmanifest in visual studio. Pressing "HoloLens" on spectator view's unity platform switcher should typically achieve enabling these capabilities, but sometimes the package.appxmanifest doesn't get updated correctly in the visual studio project with subsequent builds in Unity. You can fix this by deleting your visual studio directory and rebuilding the visual studio project in unity.
If these capabilities are checked in the package.appxmanifest, it may be that you rejected a capability request when first running the application. If you open Settings -> Privacy -> Camera on the HoloLens, you can check whether your deployed spectator view application has camera access granted. You should be able to enable the camera functionality here if it is disabled.
There have been changes to both MixedRealityToolkit and MixedRealityToolkit-Unity spectator view logic, so cloning these items at different points in time may cause functions to no longer resolve (We're hoping to consolidate this code into the same repo/commit history in the future to prevent this from continuing to happen). Typically, in the Unity logs there will be errors stating that a function was not found for SpectatorViewPlugin.dll if the dll functionality is not resolving correctly. It sounds like this is not the issue you are hitting if things worked previously. But if it does turn out the case, it may be that you need to rebuild the SpectatorViewPlugin.dll to match the feature/spectatorView code you are using.
If you recently copied the SpectatorViewPlugin.dll and its dependencies to a new unity project, it may be that they aren't getting registered as usable by the windows uwp unity player. Make sure these binaries are in a Plugins\WSA\x86 folder within your assets folder. Also check the *.dll.meta definitions in the unity inspector to ensure the dll's are declared as usable for the unity wsa player/x86 builds.
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 would like to change the output mode of an Intel GMA450 based graphics chip to "cloned" mode.
Since the environment is a Windows Embedded Standard and only one of the connected monitors might be visible for the enduser, I would like to either permanently set the output mode to cloned or reset it continuously to cloned mode in case the actual mode differs (e.g. after a reboot, disconect/reconect of the second monitor or by other means).
Is there a way (Registrykey, API for the Intel driver, Win-Api) to change the display mode to cloned / dual output programatically?
Update:
I found the SDK for the IEDG driver it seems that I might be able to programatically set the resolution, clone mode etc.
However, I can't find the SDK or any information for the driver I am currently using: Intel® Graphics Media Accelerator Driver for Windows* XP, version 14.32.4.4926.
This isn't a good answer, but it might get you headed in a direction to figure it out.
My last laptop had an external monitor connected, and the Intel drivers would often be confused about the orientation of the secondary after a reconnect or a reboot. I got tired of dealing with that and tried to fix it programatically because the clicks were too many in the GUI. Select this monitor, select rotation, select other monitor, select rotation, apply, arrange, apply, wait...
I spent about a day on it (ahh, the days of being an employee vs. self-employed!) and the solution I found was to use a program to compare the registry (regshot perhaps?) to discover what keys were involved in the correction (what they were before versus what they were after) and then there was an intel-provided exe that forced the driver to reset based on the registry-- the exe was essentially like pressing the "apply" button in the gui. I was running XP and if I recall, the gui management was for configuration of the Intel Graphics Media Accelerator Driver for Windows XP as well. So the final solution became a cmd file on my desktop that would apply a REG without confirmation and then run an exe with some parameters.
Now, I don't have that laptop (they didn't let me walk out the door with it when I quit!) and I do not remember the specifics on the exe that was required to do the reset. Just changing registry keys didn't spontaneously cause it to take effect-- there was an api call involved, which I just handled with their exe. I know that isn't a lot to go on, but something tells me the file was in the driver package, or somewhere on the drive already, and I just found it. Running it at the command line gave options. Like /reset.
I hope that helps you a little. Be sure to post back if you figure it out.
Also post back if I'm completely mistaken and it didn't happen like this at all. But that's the way I remember it. :)
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.