I'm looking for a way of programmatically removing virtual COM ports created by multiple bluetooth pairing processes. Ideally, I would like to map every new paired device ( only on at once) to the same virtual port. Can this be done via the windows setup api ?
Thanks,
dinsdale
I would look at the devcon source code in the windows DDK. I've attached the readme so you can see that it has source to do exactly what you want -- disable a serial port.
DevCon Sample
DEVCON
DevCon is a command-line tool that displays detailed information about devices, and lets you search for and manipulate devices from the command line. DevCon enables, disables, installs, configures, and removes devices on the local computer and displays detailed information about devices on local and remote computers. DevCon is included in the Windows DDK.
ABOUT THIS DOCUMENT
This document describes the DevCon source code, which is included in the Windows DDK in the /src/setup/devcon directory. It explains the DevCon design, and describes how to use the SetupAPI and device installation functions to enumerate devices and perform device operations in a console application.
For a complete description of DevCon features and instructions for using them, see the DevCon help file in the DDK documentation in Driver Development Tools/Tools for Testing Drivers/DevCon.
SCOPE
These instructions pertain to Windows XP and Windows Server 2003. DevCon was designed for use on Windows 2000, Windows XP, and Windows Server 2003. It will not work on Windows 95, Windows 98, or Windows ME.
HOW IT WORKS
Running "devcon help" will provide a list of commands along with short descriptions of what each command does. "devcon help " will give more detailed help on that command. The interpretation of each command is done via a dispatch table "DispatchTable" that is at the bottom of "cmds.cpp". Some of the commands make use of a generic device enumerator "EnumerateDevices". A few of these commands will work when given a remote target computer, and will also work if using the 32-bit devcon on Wow64. A description of some of the more interesting functions and the APIs they use follows:
cmdClasses
This command demonstrates the use of SetupDiBuildClassInfoListEx to enumerate all device class GUID's. The function SetupDiClassNameFromGuidEx and SetupDiGetClassDescriptionEx are used to obtain more information about each device class.
cmdListClass
This command demonstrates the use of SetupDiClassGuidsFromNameEx to enumerate one or more class GUID's that match the class name. This command also demonstrates the use of SetupDiGetClassDevsEx to list all the devices for each class GUID.
cmdFind cmdFindAll cmdStatus
A simple use of EnumerateDevices (explained below) to list devices and display different levels of information about each device. Note that all but cmdFindAll use DIGCF_PRESENT to only list information about devices that are currently present. The main functionality for these and related devices is done inside FindCallback.
cmdEnable cmdDisable cmdRestart
These commands show how to issue DIF_PROPERTYCHANGE to enable a device, disable a device, or restart a device. The main functionality for each of these commands is done inside ControlCallback.
These operations cannot be done on a remote machine or in the context of Wow64. CFGMGR32 API's should not be used as they skip class and co-installers.
cmdUpdate
This command shows how to use UpdateDriverForPlugAndPlayDevices to update the driver for all devices to a specific driver. Normally INSTALLFLAG_FORCE would not be specified allowing UpdateDriverForPlugAndPlayDevices to determine if there is a better match already known. It's specified in DevCon to allow DevCon to be used more effectively as a debugging/testing tool. This cannot be done on a remote machine or in the context of Wow64.
cmdInstall
A variation of cmdUpdate to install a driver when there is no associated hardware. It creates a new root-enumerated device instance and associates it with a made up hardware ID specified on the command line (which should correspond to a hardware ID in the INF). This cannot be done on a remote machine or in the context of Wow64.
cmdRemove
A command to remove devices. Plug & Play devices that are removed will reappear in response to cmdRescan. The main functionality of this command is in RemoveCallback that demonstrates the use of DIF_REMOVE. This cannot be done on a remote machine or in the context of Wow64. CFGMGR32 API's should not be used as they skip class and co-installers.
cmdRescan
This command shows the correct way to rescan for all Plug & Play devices that may have previously been removed, or that otherwise require a rescan to detect them.
cmdDPAdd
This command allows you to add a Driver Package to the machine. The main functionality of this command demonstrates the use of SetupCopyOEMInf. Adding a Driver Package to the machine doesn’t mean the drivers are installed on devices, it simply means the drivers are available automatically when a new device is plugged in or a existing device is updated.
cmdDPDelete
This command allows you to uninstall a Driver Package from the machine. The main functionality of this command demonstrates the use of SetupUninstallOEMInf. Removing a Driver Package from the machine does not uninstall the drivers associated with a device. If you want to accomplish both then use cmdRemove on all the devices using a given Driver Package and then cmdDPDelete to remove the Driver Package itself from the machine. This functionality is not available in Windows 2000 or earlier.
cmdDPEnum
This command allows you to enumerate all of the 3rd party Driver Packages currently installed on the machine and also shows you how to get some common properties from a Driver Package (Provider, Class description, DriverVer date and version).
cmdDPEnumLegacy
This command shows you how to enumerate 3rd party Driver Packages on Windows Server 2003 and earlier operating systems.
Reboot
This function shows how to correctly reboot the machine from a hardware install program. In particular it passes flags to ExitWindowsEx that cause the reboot to be associated with hardware installation. You should never reboot the machine unnecessarily.
EnumerateDevices
Demonstrates the use of SetupDiGetClassDevsEx to enumerate all devices or all present devices, either globally or limited to a specific setup class. Demonstrates the use of SetupDiCreateDeviceInfoListEx to create a blank list associated with a class or not (for most cases, a blank list need not be associated with a class). Demonstrates the use of SetupDiOpenDeviceInfo to add a device instance into a device info list. These last two API's are ideal to obtain a DeviceInfoData structure from a device instance and machine name when mixing CFGMGR32 API's with SETUPAPI API's. SetupDiGetDeviceInfoListDetail is called to obtain a remote machine handle that may be passed into CFGMGR32 API's. SetupDiEnumDeviceInfo is called to enumerate each and every device that is in the device info list (either explicitly added, or determined by the call to SetupDiGetClassDevsEx). The instance ID is obtained by calling CM_Get_Device_ID_Ex, using information in devInfo (obtained from SetupDiEnumerateDeviceInfo) and devInfoListDetail (obtained from SetupDiGetDeviceInfoListDetail). GetHwIds is called to obtain a list of hardware and compatible ID's (explained below). Once an interesting device has been determined (typically by checking hardware ID's) then the callback is called to operate on that individual device.
GetHwIds
Shows how to get the complete list of hardware ID's or compatible ID's for a device using SetupDiGetDeviceRegistryProperty.
GetDeviceDescription
Shows how to obtain descriptive information about a device. The friendly name is used if it exists, otherwise the device description is used.
DumpDeviceWithInfo
Shows how to obtain an instance ID (or use any CFGMGR32 API) given HDEVINFO (device info list) and PSP_DEVINFO_DATA (device info data).
DumpDeviceStatus
Shows how to interpret the information returned by CM_Get_DevNode_Status_Ex. Refer to cfg.h for information returned by this API.
DumpDeviceResources
Shows how to obtain information about resources used by a device.
DumpDeviceDriverFiles
Provided as a debugging aid, obtains information about the files apparently being used for a device. It uses SetupDiBuildDriverInfoList to obtain information about the driver being used for the specified device. The driver list associated with a device may be enumerated by calling SetupDiEnumDriverInfo. In this case, there will be no more than one driver listed. This function proceeds to obtain a list of files that would normally be copied for this driver using DIF_INSTALLDEVICEFILES. SetupScanFileQueue is used to enumerate the file queue to display the list of files that are associated with the driver.
DumpDeviceDriverNodes
Provided as a debugging aid, this function determines the list of compatible drivers for a device. It uses SetupDiBuildDriverInfoList to obtain the list of compatible drivers. In this case, all drivers are enumerated, however typically DIF_SELECTBESTCOMPATDRV and SetupDiGetSelectedDriver would be used together to find which driver the OS would consider to be the best.
DumpDeviceStack
This function determines class and device upper and lower filters.
BUILDING THE DEVCON SAMPLE
To build the devcon sample:
Click the Build Environment icon of choice in the Development Kits Build Environments sub-menu. This will set up the correct build environment to build this sample. Note that this sample will build in the 64-bit environments as well as the 32-bit environments.
In a command window, change to the directory containing the DevCon source code. For example:
cd src\setup\devcon
Use the macro BLD or run the following from the command prompt:
build –c
This invokes the Microsoft make routines that produce the Build.log, Build.wrn, and Build.err log files.
When the build completes, the executable will be placed in the ObjXXX\I386 subdirectory of the directory specified in the Sources file (depending on build environment chosen).
If the build does not succeed, check for these errors: 1) the build environment is not set up properly, or 2) modifications made to the sample source code introduced errors.
USING DEVCON
DevCon is provided in ready-to-run form in tools\devcon. For usage, refer to the document provided with devcon.exe. DevCon is a command line utility with built-in documentation available by typing "devcon help".
TESTING
Type "devcon find *" to list device instances of all present devices on the local machine.
Type "devcon status #root\rdp_mou\0000" to list status of the terminal server mouse driver.
Type "devcon status PNP05" to list status of all COM ports.
Related
I'm setting up a test environment including several instruments connected via LAN(TCP/IP) or USB. A Software shall be written in C# using the Ivi.Visa library. The instruments (which will change over time) get their IP address from a DHCP server so they won't show up in the Resources discovered byIVI.Visa.interop.ResourceManager.FindRsrc() unless they've been previously added by the Keysight Connection manager Software (or equivalent NI tool).
ResourceManager rMgr = new ResourceManager();
string[] enumRcrs = rMgr.FindRsrc("?*INSTR");
How does one achieve to discover new VISA Network devices in C# and add them to the resources list without having to use the external software before?
Modern instruments may support discovery via mDNS (see LXI specification here). I'm not familiar with Ivi.Visa library, but you may want to look over its documentation for instrument discovery feature. If it is not supported then you can probably implement mDNS request in your C# code.
In an effort to automate some phone calling processes and integrate TAPI3 with another application, I am using to following code that was found as a sample;
tapi = new TAPI3Lib.TAPIClass();
tapi.Initialize();
foreach (TAPI3Lib.ITAddress ad in (tapi.Addresses as TAPI3Lib.ITCollection))
cbLines.Items.Add(ad.AddressName);
This code fills the devices in a dropdown and the dropdown only contains one device and it only shows from my computer. I tried installing the PIMphony_6.8_bld3200_XX_Alcatel on other computers where i add the IP address of the PBX device and a phone number (ex: 106) but it does not even show in the list the one device that i can see on my computer. I whatsoever have no idea what and how i managed to be able to see the device on my computer when i run this code. Obviously i am missing something. The devices we are using are Alcatel and the phone can be controlled by this app only on my computer. (i can provide the zip file containing PIMphony_6.8_bld3200_XX_Alcatel if needed). So the ultimate goal is to be able to see telephone lines on all computers so we can control them from the computer.
What am i missing Tapi3 experts? is it a missing installation on the other pc's ? and why only my device shows up?
You need a 3rd party TAPI driver installed, it might be on a DVD with the PBXor on some support website, but some manufacturers charge extra for it. This PIMphony looks like a phone control tool but that does not guarantee it is using TAPI under the hood, it may be using some propitiatory protocol.
I don't know TAPI3 but if you use TAPI correctly you should see 3 to 4 standard windows builtin devices (like WAN miniports) even if you have no drivers installed.
You need a decent test tool to compare results with, I would recommend phone.exe, it is kind of the standard test tool in the TAPI business. But it's getting harder to find online these days, here is a link to a slighly extended variant that google got me quickly: https://helpdesk.estos.de/Knowledgebase/Article/View/82/3/howto-ephoneexe--tapi-test-tool
This is not WinRT application. It's standard WPF. The device behaves as normal Windows PC, has Windows 10 installed. It has 3G broadband modem and a SIM card slot.
Some more information would be helpful. For example the brand and connection type (usb/internal).
If I understood you correctly you are looking for a solution to programmatically (in wpf) collect information (imei) about connected modems (in general or only one specific?)
Depending on the device you have several options.
Option 1 WMI:
Depending if the manufacturer included the information you might be successful by an simple WMI query.
To verify this take a look at the Device Manager (start -> run -> devmgmt.msc)
Right Click on your Modem -> Properties
Now go the register "Details".
Scroll through the Properties and look for your IMEI (the property doesn't necessarily is named IMEI). If you find it there, you can use a WMI Query to get the information into your WPF program.
Example here: http://www.codeproject.com/Questions/448125/How-to-write-WMI-Query-to-find-USB-MODEMS-IN-Cshar
Option 2 AT Commands:
If you are able to communicate with the modem over serial connection you can use so called "AT-Commands" to get the IMEI.
Information about the AT Commands can be found here: http://www.developershome.com/sms/atCommandsIntro.asp
I am looking into making a c# program that will read in the logcat output from an android device and read it in to the c# program.
Initially it should do this while the phone is connected and it shouldn't require a specific app on the phone to be installed for the c# program to be able to retrieve the logcat output. Also the phone shouldn't require root access.
Is this something that is possible, I can't find anything on Google that says its possible but thought I'd ask on here in case someone has some useful information.
Thanks for any help you can provide
The most practical answer is to execute the shell command 'adb logcat' from your C# program and capture its output.
The only requirement for the device is that USB debugging be enabled in the settings menu.
The host PC will require that the android developer tools and appropriate USB driver for the device be installed. This can, unfortunately involve a substantial amount of hassle, especially finding the right drivers for windows hosts.
More complicated approaches would be to duplicate the functionality of the adb program (it is open source) and/or USB driver in your program, or to install an app on the device with the read logs permission which sends them to you - or even run an ssh server under the app userid so you can connect in and obtain them.
I have a device and the drivers for this device. What I would like to do is build an application that mocks a USB device to communicate with a third party application.
More specifically, I am attempting to build an application that can mock a USB device that mimics a Microsoft Zune. I want to make it so my application can register as a zune device and then communicate with the client. I have added several DLL's to my application in order to attempt to determine the calls that tell the software a connected device is a legitimate zune, but so far I haven't had much luck.
I'm new to this type of development - that is mimicking hardware devices, and I'm not very experienced in importing dll's that were written in C/C++. I am using Visual Studio 2010 (.net 4.0) to develop my app, and I would appreciate any help anyone can offer me towards mimicking the hardware. I do have the device drivers, which Visual studio refuses to reference directly. I also have an actual physical device, so I can see what the drivers are that it uses in Device Manager.
The goal is as follows
Application registers itself as a usb device, mimicking a Microsoft Zune in a similar fashion to how Virtual Clone Drive mimics a DVD player.
Application is recognized by zune client as a valid microsoft zune.
Zune Software works with application as it does the hardware device (syncing, etc)
I just found something called the Device Simulation Framework, which might be exactly what you need. It will still require significant research into how USB works to finish your solution, though. And probably still typically done using C or C++.
The Zune uses a modified version of the MTP protocol called MTPZ, but I found this sample using the Device Simulation Framework to simulate a regular MTP device. It's called The MTP Device Simulator. I can't tell if source code is available.
Are you able to replace the DLLs used by the zune client software with your own DLLs? In that case, you could wrap the original DLLs with your DLLs and intercept the operations.
Update: To find out the signatures of the functions in the DLL, take a look at the Dependency Walker tool, which will list the exported functions (and lots of other information). I'm guessing you will want to write your replacement DLL in C.
Otherwise, you'll have to write drivers that register a USB device with the proper endpoints. I'm not sure how to do this on Windows - I've only done USB coding on the firmware side, not the driver side. You should be able to use any tutorial for creating a Windows USB driver, like Getting Started with USB Driver Development
Zune specifics information might also be useful. Perhaps this blog post and its sequels could help: Inside the Zune/USB Protocol: Part 1