I'm trying to open a serial port in a Universal app following the instructions found in https://ms-iot.github.io/content/en-US/win10/samples/SerialSample.htm
My app has the correct DeviceCapability in Package.appxmanifest and I can enumerate correctly all the devices and all of them are found when calling to:
var selector = SerialDevice.GetDeviceSelector();
var devices = await DeviceInformation.FindAllAsync(selector);
The problem arise when I try to open any of the serial ports. The call to SerialDevice.FromIdAsync always returns null.
var serialPort = await SerialDevice.FromIdAsync(devices[0].Id);
Then, as explained in https://channel9.msdn.com/events/Build/2015/3-81, I try to analyze the problem calling to DeviceAccessInformation.CreateFromDeviceId and the surprise is that this call throws a FileNotFoundException.
The string I'm passing to DeviceAccessInformation.CreateFromDeviceId is:
"\\?\ROOT#UBLOXVCP#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}"
but it also throws the exception with:
"\\?\ACPI#PNP0501#1#{86e0d1e0-8089-11d0-9ce4-08003e301f73}"
both of them throws the FileNotFoundException.
In the Channel 9 video, Arvind Aiyar says something like you can reboke the access to the serial ports with the Privacy configuration of Windows 10, but I can't found anything in relationship with Serial Ports in the Privacy configuration.
To test what's happening I tried to disassembly the DeviceAccessInformation.CreateFromDeviceId method with dotPeek and no way to access to the WinRT part so I decided to call to a different API.
If you search {86e0d1e0-8089-11d0-9ce4-08003e301f73} you'll see that it is the device interface class is defined for COM ports, so I called to:
DeviceAccessInformation.CreateFromDeviceClassId(new Guid("{86e0d1e0-8089-11d0-9ce4-08003e301f73}"));
and this method doesn't throws any exception and returns DeviceAccessStatus.Unspecified
I am using Windows 10 Pro x64 version 1511, compilation 10586.71, Visual Studio 2015 Update 1.
Am I doing something wrong?
Is all about permissions?
Related
I have tried to use the sample of code from microsoft documentation in order to connect to a hid device: https://learn.microsoft.com/en-us/uwp/api/windows.devices.humaninterfacedevice.hiddevice?view=winrt-22000
I have made a C# console application and also a UWP application, but with both of them I encounter the same behaviour.
Even though my device is found there:
string selector =
HidDevice.GetDeviceSelector(usagePage, usageId, vendorId, productId);
var devices = await DeviceInformation.FindAllAsync(selector);
I cannot open it for read/write and this line of code manages to close my application with no errors:
HidDevice device =
await HidDevice.FromIdAsync(devices.ElementAt(0).Id,
FileAccessMode.ReadWrite);
Has anyone experienced this and may have a solution to it?
Thank you!
I'm currently using CefSharp in an application and trying to load a web page hosted on port 6668 and the web page is unable to load but hosting the web page on a port chromium doesn't consider unsafe works.
List of restricted chrome ports
For chrome there is a command line arg for explicitly allowing unsafe ports
ex: chrome.exe --explicitly-allowed-ports=81,84,87
However I don't see any information that says CEF supports or doesn't support this command line argument or has a way to allow unsafe ports.
I've tried adding the argument before initialization but it still doesn't allow the port. I've also tried putting a "-" or "--" before explicitly-allowed-ports just to test it in the example below but neither work. Not including the preceding -'s seems to be correct from looking at the CefSharp example as well.
var settings = new CefSettings();
settings.CefCommandLineArgs.Add("explicitly-allowed-ports", "6000,6665,6666,6667,6668,6669");
Cef.Initialize(settings);
Is there another way to allow restricted ports for CEF or does CEF just not support this command line arg?
Looks like CEF would need to be patched to make the net::SetExplicitlyAllowedPorts call in the browser process. See https://cs.chromium.org/chromium/src/chrome/browser/ui/startup/startup_browser_creator.cc?l=593&rcl=e756eda1d880f2481c88b1e599963e8f46b8b485 .
I'm playing around with remote UWP AppServices in C# and I run into a very early roadblock: Getting a RemoteSystem instance.
I followed the tutorial on https://msdn.microsoft.com/en-us/windows/uwp/launch-resume/communicate-with-a-remote-app-service with my own code and I tried out the RemoteSystems sample as part of https://github.com/Microsoft/Windows-universal-samples
Unfortunately, the result is always the same.
First I request access to remote systems:
RemoteSystemAccessStatus status = await RemoteSystem.RequestAccessAsync();
This is successful: status has the value RemoteSystemAccessStatus.Allowed.
Next, I create a HostName instance:
var deviceHost = new HostName("computer2");
Then I want to get a RemoteSystem instance:
RemoteSystem remoteSystem = await RemoteSystem.FindByHostNameAsync(deviceHost);
This throws an exception:
Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))
What I tried
Searching the web doesn't bring up much at this time (remote UWP AppServices are too new)
The event log doesn't have anything interesting in it
The Windows firewall seems to be configured correctly (this seems to be done automatically by Visual Studio)
What I'm looking for
One of my computer was upgraded from Windows 7 to Windows 10, the other from Windows 8.1 to Windows 10. So there is a chance my computers are "misconfigured" in some way (I remember the unnecessary task scheduler entries for Windows Media Center...)
My question: What are recommended practices to troubleshoot these kinds of problems? Are there tools that can help me? Right now I'm now even sure where to start looking...
I am taking what was traditionally a single-instance-only application and updating it so multiple instances can execute on the same PC. Each instance will require exclusive access to a USB device. The first application instance opens a USB device with the following command (some Kernel32 wrappers for C# are in place) and gets a valid handle, as expected:
this.handle = Kernel32.CreateFile(
pathToUsbDevice,
Convert.ToUInt32(FileRead.Read | FileRead.Write),
Convert.ToUInt32(FileShare.None),
IntPtr.Zero,
Convert.ToUInt32(CreateDisposition.OpenExisting),
Convert.ToUInt32(FileFlags.Overlapped),
IntPtr.Zero);
The problem is that I then open the second instance of the application and it is able to also get a valid handle to the same device (while the first instance still has its handle). This seems incorrect to me, as my understanding of CreateFile is that it should return an invalid file handle if that device is already opened exclusively (sharing set to 0, or None).
Am I doing something wrong in CreateFile? Perhaps my assumption that it will return an invalid handle if the device is already exclusively opened is incorrect? How can I exclusively open the device for a single application instance so that other application instances cannot open it?
In case it matters, the development & test PC is Windows 7 Professional, 64-bit, building the app via Visual Studio Express 2013.
Looks like it is a device driver issue. I've found a similar discussion:
It's up to the driver to manage shared/non-shared, not the IO manager. So you
have two choices:
Mark your device exclusive in the INF (see the Exclusive registry value under
http://msdn.microsoft.com/en-us/library/windows/hardware/ff546320(v=3Dvs.85).aspx
)
Add file create/close handlers in your driver and manage the count of clients
yourself
You might want to use some other approach to ensure only one instance of your app is accessing device (like using a named global mutex to guard device access).
I am developing a C# device application for Motorola MC55 devices (Bluetopia is used). This application sets the bluetooth inquiry and pairing procedure in motion (by means of the Enterprise Mobility Developer Kit) and writes down the virtual serial port #:
public void DoConnection(IRemoteBTDevice rd)
{
RemoteDevice remoteDevice = new RemoteDevice(rd.DeviceName, rd.Id.Replace(":", ""), "");
this.bluetooth.RemoteDevices.Add(remoteDevice);
this.bluetooth.RemoteDevices.Refresh();
if (!remoteDevice.IsPaired)
{
remoteDevice.Pair(rd.Pin);
}
//TODO Note serial port # (get it by means of remoteDevice.LocalComPort)
//Works smoothly, but a second process has to do this (requirement).
remoteDevice.OpenPort();
}
But as soon as a second process (e.g. another c# device application) opens that serial port, BTExplorer is launched. How do I suppress this phenomenon?
this.comX = new SerialPort(this.BluetoothPortName);
this.comX.Open();
I'm just using another Assembly: http://32feet.codeplex.com/. It works smoothly for Motorola ES400 (Microsoft Stack). After seeing this: http://32feet.codeplex.com/wikipage?title=Stonestreet%20One%20Bluetopia, I used the same code, but it doesn't work trouble-free for MC55 yet.
Thank you for your support,
Roger Huber
As I understand it, it is BTExplorer.exe that actually provides/controls the virtual COM port service, so it needs to be running when a virtual COM port is in use...
Do be sure to let know what the issues you see on your MC55 when using my 32feet.NET Bluetopia support. As I noted at 32feet.NET: Stonestreet One Bluetopia I tested on a M3 Mobile device which has a quite recent version of the Bluetopia stack. Maybe StoneStreetOne changed something between your versions... (If Bluetopia start-up fails completely then I've more logging in version 3.3 -- which I'm not too far away from releasing).
Of course if that second C# program needs to use a virtual COM port then 32feet.NET won't help -- BTExplorer is still required as discussed above. However if you could change that program to use BluetoothClient etc instead of COM ports... (Remembering of course the "Bluetopia one at a time" restriction of course).
Alan