I want to write a Windows service (in c#) or a powershell script that connects my laptop automatically (at boot or key combination) to my MS wireless display adapter for screen mirroring. In Windows 10 I can only do it manually by going to the notifications and click Connect>MS Wireless adapter>connect.
What I found is that there is a Miracast API but there is not much documentation on how to use it.
I also found this documentation on MiraDisp.dll and there are two functions OpenMiracastSession and CloseMiracastSession.
The problem is I don't know how to use these functions in c#. I know I will probably have to use pInvoke. Can anyone point me in the right direction?
First of all, thanks to #CodingGorilla for the suggestion on AutoHotkey. I've been playing around with that the past couple of days.
I went the AutoHotkey route as I couldn't find an easy place to start with any Windows 10 API. All kinds of documentation out there to push toast notifications but I couldn't find anything to control the action center. If anyone has suggestions on that front, please post them.
Here is what I came up with using AutoHotkey. Pretty simple but not an ideal solution as there are a few variables with this. Below is AutoHotkey script code I used to open the action center, click connect, then click the top-most listed wireless display:
Send #a ;Sends Windows button + A to open the action center
Sleep, 750 ; Give it some time to slide open
ImageSearch, FoundX, FoundY, 0, 0, A_ScreenWidth, A_ScreenHeight, C:\Connect.png ;Try to find the Connect button tile
if ErrorLevel = 2
MsgBox Could not conduct the search for the connect button in action center. Make sure your search image is in the correct location.
else if ErrorLevel = 1
MsgBox Connect button cannot be found on the screen.
else
MoveMouseAndClick(FoundX, FoundY)
Sleep, 1250 ;Delay so the wireless displays have a chance to load into the Action Center window
ImageSearch, FoundX, FoundY, 0, 0, A_ScreenWidth, A_ScreenHeight, C:\WirelessDisplay.png
if ErrorLevel = 2
MsgBox Could not conduct the search for the wireless display.
else if ErrorLevel = 1
{
;Search image cannot be found. Try 1 more time in case it took a long time for the wireless displays to appear
Sleep, 750
ImageSearch, FoundX, FoundY, 0, 0, A_ScreenWidth, A_ScreenHeight, C:\WirelessDisplay.png ;try to find the first Wireless Display device listed
if ErrorLevel = 1
MsgBox Wireless display image cannot be found on the screen. Make sure the wireless device is turned on.
else
MoveMouseAndClick(FoundX, FoundY)
}
else
MoveMouseAndClick(FoundX, FoundY)
Send {Esc} ;Send Esc to get rid of the Action Center window
Return
MoveMouseAndClick(x, y) {
MouseMove, x + 25, y + 25 ;Move it down the right a bit to make sure we click the button
Sleep, 250
MouseClick, left
}
I've also attached the images as an example of what I made. You will need to make your own search images. Before making those images, you must also turn off the transparency of the Action Center, start and taskbar in Windows 10 - Settings->Personalization->Colors->Make Start, taskbar, and action center transparent->Off. It is especially important to redo the 2nd image as mine image lists "Roku Stick" within the image. I had to redo my search image between my desktop development machine and the MS Surface 3 I'm running this script on. Resolutions and such will change between devices. Follow the instructions on how to create your own search image here:
https://autohotkey.com/docs/commands/ImageSearch.htm
Lastly, this likely won't work if the wireless display is already connected. In my environment connecting the wireless display causes the resolution on the tablet to change and therefore it can't find the images on screen.
First I want to say that #jaredbaszler has provided a really good solution. It worked like a charm thank you :)
I was playing around with AutoHotkey too since I wanted to find out if there is another way to do this. After a while I came up with the following script:
Send #k ; Sends Windows button + K to open the Action Center Connect window
Sleep, 3000 ; Wait some time so the wireless display dongle can be found
Send {Enter} ; Send ENTER key to connect to wireless display dongle (works when only 1 is found)
Send {Esc} ; Send ESC key to close the Action Center Connect window
Ok. Now let me explain how this script works:
First it will press WIN+K which will open the Action Center Connect window
Then it will wait for 3 seconds so that the wireless display dongle can be found (You can adjust this value as you please but I needed to wait more than 2 seconds for my wireless display dongle to show up)
After the wait it will press ENTER which will automatically choose the first wireless display dongle in the list and trigger the connect function (If no wireless display dongles can be found your Default Browser will open the "Help" link)
The last thing the script does is to press the ESC key to close the Action Center
Well, that´s it. It´s nothing special but it works. I have tested this script a few times with my tablet and my wireless display dongle (I have this one here) and it seems to work just fine.
Unfortunately my script will not work as expected if you have multiple wireless display dongles up and running at the same time because my script will simply choose the first one that shows up. (This is not a problem for me since I only have one wireless display dongle)
The question is a bit old, but currently I've faced the same problem.
I suggest writing a UWP App utilizing the ProjectionManager class according to sample 5 + 6 in the Advanced casting sample.
The essentially steps are:
getting a DeviceID (for example by picking with DevicePicker class)
calling ProjectionManager.StartProjectingAsync(newViewId, currentViewId, selectedDeviceInformation) to start the projection
The DeviceInformation object can be obtained by calling DeviceInformation.CreateFromIdAsync() using the acquired (and saved) deviceId.
The viewIds may be set to 0 (or other invalid values) the projection is starting anyway.
If the projection has started, the app can be closed, the projection is still keeping alive.
If anyone is interested in the solution, I will upload the code to GitHub.
This was the AutoHotKey script that I wrote;
Run, explorer.exe ms-settings-connectabledevices:devicediscovery
Sleep, 800
Send, {Tab}
Send,+{Tab}
Send,{Enter}
Sleep, 200
; then next Send command types the first few letters of the name of the WiDi adaptor
Send, Microsoft
Sleep, 200
Send, {Tab}
Sleep, 200
Send, {Enter}
To automate and control Miracast, you want to write a UWP app using the Windows.Media.Casting namespace and Windows Universal Samples.
They can be written in many common languages including C#, C++, Javascript, and Visual Basic.
Windows provided two sets of functional sample programs to demonstrate what you can do with Miracast that can be opened and launched as Visual Studio solutions (.sln).
Basic Casting
Advanced Casting
Because UWP apps are designed to be made available on the Windows app store, they have specific requirements and regulations for functioning. (I recommend researching these.)
Also avoid the pitfall I made when I started writing a generic program and then wondered where the Universal Windows library was:
Starting a UWP project
I ended up using the vbs-based solution from here:
https://superuser.com/questions/1062789/how-to-connect-to-a-wireless-display-adapter-automatically-through-scripts-or-ta
While it basically does the same steps, I found this much more robust than the other solutions. What is more, vbs is available (I think) on most Win machines.
Related
I'm getting this error...
The semaphore timeout period has expired.
On this line...
ThePorts.ActivePort1.Open();
...but I only get it from time to time. When it happens, it happens over and over again. Then the problem goes away, for hours or days, then it comes back.
The serial port is a USB with a BlueTooth connected.
I think this guy was having a very similar problem, but not in C#
Freeze on SerialPort.Open / DeviceIoControl / GetcommState with usbser.sys
As best I can estimate, I have read his entire problem, and the resulting comments, and the answer, but I really can't figure out which one fixed his problem, or if C# is significantly different from what he was experiencing.
Thanks for any help for the clueless. This is the actual code where it's happening.
public static void Open_ActivePortWeWillUse(String Drone_StringNameFromUser)
{
SerialPort TempSerialPort = new SerialPort(Drone_StringNameFromUser, (int) SerialPortSpeed);
ThePorts.ActivePort1 = TempSerialPort;
ThePorts.ActivePort1.DataBits = 8;
ThePorts.ActivePort1.Parity = Parity.None;
ThePorts.ActivePort1.StopBits = StopBits.One;
ThePorts.ActivePort1.DataReceived += new SerialDataReceivedEventHandler(OurBackGroundSerialPortReceiver);
ThePorts.ActivePort1.Open(); // "Sometimes" Error hits here
}
Okay, I am now connecting without the semaphore timeout problem.
If anyone reading ever encounters the same thing, I hope that this procedure works for you; but no promises; hey, it's windows.
In my case this was Windows 7
I got a little hint from This page on eHow; not sure if that might help anyone or not.
So anyway, this was the simple twenty three step procedure that worked for me
Click on start button
Choose Control Panel
From Control Panel, choose Device Manger
From Device Manager, choose Universal Serial Bus Controllers
From Universal Serial Bus Controllers, click the little sideways triangle
I cannot predict what you'll see on your computer, but on mine I get a long drop-down list
Begin the investigation to figure out which one of these members of this list is the culprit...
On each member of the drop-down list, right-click on the name
A list will open, choose Properties
Guesswork time: using the various tabs near the top of the resulting window which opens, make a guess if this is the USB adapter driver which is choking your stuff with semaphore timeouts
Once you have made the proper guess, then close the USB Root Hub Properties window (but leave the Device Manager window open).
Physically disonnect anything and everything from that USB hub.
Unplug it.
Return your mouse pointer to that USB Root Hub in the list which you identified earlier.
Right click again
Choose Uninstall
Let Windows do its thing
Wait a little while
Power Down the whole computer if you have the time; some say this is required. I think I got away without it.
Plug the USB hub back into a USB connector on the PC
If the list in the device manager blinks and does a few flash-bulbs, it's okay.
Plug the BlueTooth connector back into the USB hub
Let windows do its thing some more
Within two minutes, I had a working COM port again, no semaphore timeouts.
Hope it works for anyone else who may be having a similar problem.
This error could also appear if you are having network latency or internet or local network problems. Bridged connections that have a failing counterpart may be the culprit as well.
I had this problem as well on two different Windows computers when communicating with a Arduino Leonardo. The reliable solution was:
Find the COM port in device manager and open the device properties.
Open the "Port Settings" tab, and click the advanced button.
There, uncheck the box "Use FIFO buffers (required 16550 compatible UART), and press OK.
Unfortunately, I don't know what this feature does, or how it affects this issue. After several PC restarts and a dozen device connection cycles, this is the only thing that reliably fixed the issue.
Too many big files all in one go. Windows barfs. Essentially the copying took too long because you asked too much of the computer and the file locking was locked too long and set a flag off, the flag is a semaphore error.
The computer stuffed itself and choked on it. I saw the RAM memory here get progressively filled with a Cache in RAM. Then when filled the subsystem ground to a halt with a semaphore error.
I have a workaround; copy or transfer fewer files not one humongous block. Break it down into sets of blocks and send across the files one at a time, maybe a few at a time, but not never the lot.
References:
https://appuals.com/how-to-fix-the-semaphore-timeout-period-has-expired-0x80070079/
https://www-01.ibm.com/support/docview.wss?uid=swg21094630
I had a similar problem which I solved by changing the Port Settings in the port driver (located in Ports in device manager) to fit the device I was using.
For me it was that wrong Bits per second value was set.
I was this problem with program RealTerm, then I entered into device manager and just disable the Bluetooth device connected into the port COM3.
The problem is with your cable not with your code or connection some cables are designed to send power only some are designed to send power and data we have to see those types of cables
I recently purchased a lenovo t420 laptop. I upgraded it with an SSD and did the update from 7 to 10. I then installed a clean image of windows 10, without all the bloatware. I would like to have access to the keyboard light without installing the Lenovo software. It isnt a backlight but is a single white LED next to the camera above the display. I see it come on for a split second when I cold boot the machine, I'm assuming this is part of the POST test or similar boot process and as such I would think there would be some way for me to connect to it.
I have tried using the new Lamp class in the windows 10 UWP API, and that doesnt work. I also tried using the device enumeration method and that doesnt show anything that looks like the LED.
Here is the code I tried so far, condensed a bit.
Lamp lamp = await Lamp.GetDefaultAsync();
this reults in lamp = null
string selectorString = Lamp.GetDeviceSelector();
DeviceInformationCollection devices = await DeviceInformation.FindAllAsync(selectorString);
this also results in null
this is the device enumeration code:
DeviceInformationCollection devices = devices = await light.EnumerateDevices();
This gives me about 291 different devices in the collection, none of which seem to match. I have held back on posting here as the list is long but can if requested.
Is there any way for me to access the LED through C#, if not C# than perhaps another language?
EDIT: I just found the keyboard key, I had bad info before, its Fn + Pgup. That works so i guess I dont need to write something myself but I am still curious as to why I cant find a hook to it.
As a learning exercise I would still like to know how to access the LED.
Ok, so I think this is as close as I am going to get to an answer and I would like to put it here for any future curious minds.
Here is a link to a page with a bunch of info on how to get at the ThinkLight from Linux and Windows.
http://www.thinkwiki.org/wiki/ThinkLight
And here is the important stuff in case the link breaks.
Controlling the ThinkLight with the keyboard works on all systems since it relies on the BIOS exclusively. Just press Fn+PageUp to toggle its state between on and off.
Starting with the ##30 series models (T430, T530, W530, etc), the keystroke was changed to Fn+Space in order to better accommodate the new 6-row keyboard layout. On models with backlit keyboards, there are 4 states: off, dim backlit, full backlit, and full backlit w/ ThinkLight. Models without backlit keyboards only have ThinkLight on and ThinkLight off, which can be obtained by disabling the backlit keyboard in the BIOS of models with backlit keyboards installed.
Software Control via thinkpad-acp
Software Control via thinkpad-acpi
Support for controlling the light with ACPI is provided by thinkpad-acpi. After installing it, a simple
# echo 255 > /sys/class/leds/tpacpi\:\:thinklight/brightness
switches it on and a
# echo 0 > /sys/class/leds/tpacpi\:\:thinklight/brightness
switches it off again.
This allows one to control the light in scripts. Unfortunately, no known ThinkPad comes with a light sensor (yet). ;)
To use these controls in scripts without root permissions, you should run
# chmod 666 /sys/class/leds/tpacpi\:\:thinklight/brightness, which is probably best done using udev.
Applications
led-notification: Pidgin plugin to use any LED to indicate new
messages. I've forked led-notification to support the ThinkLight via
thinkpad-acpi. The plugins below either weren't compatible with the
latest pidgin or didn't compile for me. The original author of
led-notification seems MIA. Another fork pidgin-led-notification to
write user defined strings (added to Gentoo/Linux)
gaim-thinklight: If you are using GAIM, the gaim-thinklight plugin
will enable you to use the ThinkLight as an indicator for new
messages. This depends on thinkpad-acpi.
gaim-lighthink: gaim-lightthink is an alternative to gaim-thinklight.
pidgin-blinklight:pidgin-blinklight is a replacement for
gaim-lighthink intended for use with Pidgin.
rocklight: rocklight is a xmms visualization plugin that makes the
ThinkLight flash to the beat of your music. The package also includes
a standalone stroboscope mode program.
thinkblinkd:[1] Thinkblinkd is a python daemon to control the
thinklight (and possibly other lights on your Thinkpad) it comes with
the daemon and a control script.
The script for theft alarm using HDAPS optionally flashes the
ThinkLight when the alarm is armed (disabled by default, to enable
set $use_light=1).
kopete-thinklight:[2] This plugin for kopete will enable the usage of
the thinklight as notifiaction for new messages. stupid little hack
to blink the ThinkLight: [3] A little C program that may be set SUID
so that you can use it from non-privileged programs that needs to do
a little notification.
thinkalert: [4] Another C program that may be set SUID to allow
non-privileged programs to manipulate the ThinkLight. Adds some
features over the "stupid little hack to blink the ThinkLight"
program.
thinklight-notification: This Evolution plugin notifies the user with
a blinking light whenever a new message has arrived.
ThinkBlink: blink.sh is an universal bash script making ThinkLight
blink. It can be used with any application.
Windows support
Likewise, controlling the ThinkLight with the keyboard works without any additional software. The Hotkey Features software from IBM/Lenovo adds OSD icons that appear when the light is turned on/off.
Software control via Hotkey Features
The Hotkey Features software exposes an interface that allows (among other things) to control the ThinkLight. See Python script for Windows to control ThinkPad features for more information
We have a C# tool (that I wrote) that records online broadcasts taking place a custom written (that we wrote) flash app. (There are no DRM or copyright issues here.)
We've coded up a system whereby this tool is installed on a Windows Server 2012 R2 Amazon AWS instance. After we boot the instance, the tool loads, waits for the right time to start recording, launches a browser and passes the command line argument of the URL to access the broadcast. The browser will then load the flash app and the interview audio and video will start arriving at the browser instance on AWS
By way of a virtual audio cable driver, screen / audio capture directshow filters and ffmpeg a screen recording is taken. The C# tool calls ffmpeg and ffmpeg will record the screen reliably for the entire interview, then the tool shuts the whole thing down
The problem I'm having is that both Chrome and Electron browser sometimes simply don't draw themselves on the screen so all ffmpeg ends up recording is a blank desktop and the audio of the broadcast (hence, the browser IS running)
We found this out when recordings started turning up with X hours of merely recording the windows desktop and the tool's main window with a countdown timer.
A screenshotting facility was built into the tool and added to its web control interface, and this way we can test whether the browser is visible - a human looks at the screenshot of every broadcast, just after recording has started (the browser is supposed to be on show by this time)
We notice that 50% of the time, the browser isn't drawing itself on screen. By 50% I mean that every other recording that the AWS instance carries out, will be blank: AWS starts, records ok, shuts down. AWS starts again an hour later for a different broadcast, recording is blank, shuts down.. Starts/ok/shutdown. Starts/blank/shutdown. Repeat ad infinitum
What's even more strange is that if I run VNCviewer on my dev machine and connect up to an instance that is having a problem, the instant that the VNC connection is up and the remote desktop is showing on my screen, the browser suddenly appears as if nothing was ever wrong. A screenshot from before the VNC connect shows blank desktop, connect VNC, take another screenshot and the browser is there. All through it the audio is fine - the browser connected to the boadcast is fine, for sure
It's as though Chrome/Electron thinks "you know what, noone is looking at me so I'm not going to bother drawing myself". No screen saver is set, though the power plan has the setting "turn off the display after 15 minutes".
Perhaps Chrome/Electron have a test amounts to "if the display is off, don't draw". I can't explain the inconsistency though - the recorder launches at least 1 hour before it's needed, and sits there idle until it's time to start the browser. You'd hence imagine that the "power off the monitor after 15 mins" setting would reliably have ensured the "monitor" is "off" by the time every recording start comes around
This behaviour doesn't happen with any of the other browsers (but unfortunately the app doesn't and cannot work in them because it uses some weird chrome-only technology/API).
Can anyone suggest anything to look at to help debug this, or anything I can build into the C# tool to overcome the problem? Coding it up to connect to itself via VNC for a few seconds after it has launched the browser.. Well that just tastes nasty.
Naturally, as soon as I connect to the machine via VNC (rather than RDP - RDP isn't usable because the recording context is in a logged on session for a particular user) the problem goes away, which makes it frustratingly hard to debug.
I am not sure what exactly causes your problem, but it sounds like interacting wit the system prevents it. One way to interact with a system is to use the keyboard and this can be automated.
You could try sending a keystroke (like "F15") evey so many seconds in C# using
Windows Input Simulator or maybe SendKeys.Send and
Combine the above with some kind of Timer
Maybe take a quick peek at this app called Caffeine...it presses the "F15" key for you every so many seconds. They claim "F15" generally doesnt trigger anything in windows (since a release they made back in 2010).
Caffeine App
I use as USB-SerialPort Converter for a Barcodereader. (Drivers for the converter are supplied on a CD -- company: digitus)
In my program (C#) I wait for SerialPortDataReceived-Events and proceed if I get values -- so far everything works fine.
The problem now is that I don't receive Data anymore sometimes.
The same readers and USB-RS232 converters as well as the same notebooks (lenovo, Win7) are used at 8 stations, but only at 2 of them I have this problem.
When I am in the situation that I do not receive Data when the reader read some, I can't see any problem. Windows says that the serial port is working fine.
But when I unplug the power supply of the reader and reconnect the COM-Port in my program it works again.
(And I do not think that the reader is the problem, because those readers are used a couple of hundred times in the company I work for)
So it must be the converter or the cooperation from the converter and the barcode reader!?
My next idea would be trying another converter, but is there any way to understand the cause?
Or did anybody have a similar problem?
Try disabling the "USB selective suspend" feature
Open Control Panel.
Click on Hardware and Sound.
Click on Power Options.
Click the Change plan settings link for the plan you're currently using. (If you change the settings on the power plan that isn't active, this won't work.)
Click the Change advanced power settings link.
Expand USB settings.
Expand USB selective suspend setting.
Select Disabled from the drop-down menu.
Click Apply.
Click OK.
If you're changing the settings on a laptop or tablet, you'll see two options: On Battery and Plugged in, so make sure to change those settings accordingly.
Once you complete these steps, Windows 10 will no longer power off USB devices connected to your computer, which can fix any problem you may have as a result of this feature.
While this guide focuses on Windows 10, USB selective suspend has been around for a long time, and you can use the same steps on machines running Windows 8.1 and Windows 7.
For more details check https://www.windowscentral.com/how-prevent-windows-10-turning-usb-devices#:~:text=When%20a%20USB%20device%20is,feature%20to%20fix%20the%20problem.&text=Windows%2010%20includes%20the%20USB,re%20not%20actively%20in%20use.
USB ports are terribly unreliable in this way. The only way to get a reliable serial.port is to use a PCI card or an Ethernet device server. You will never get a consistent connection through USB.
We get a bug reported in our serial port comms about one a month, and every single occurrence is due to someone using a USB to RS232 converter. As soon as we install better hardwarec the issue vanishes.
I'm getting this error...
The semaphore timeout period has expired.
On this line...
ThePorts.ActivePort1.Open();
...but I only get it from time to time. When it happens, it happens over and over again. Then the problem goes away, for hours or days, then it comes back.
The serial port is a USB with a BlueTooth connected.
I think this guy was having a very similar problem, but not in C#
Freeze on SerialPort.Open / DeviceIoControl / GetcommState with usbser.sys
As best I can estimate, I have read his entire problem, and the resulting comments, and the answer, but I really can't figure out which one fixed his problem, or if C# is significantly different from what he was experiencing.
Thanks for any help for the clueless. This is the actual code where it's happening.
public static void Open_ActivePortWeWillUse(String Drone_StringNameFromUser)
{
SerialPort TempSerialPort = new SerialPort(Drone_StringNameFromUser, (int) SerialPortSpeed);
ThePorts.ActivePort1 = TempSerialPort;
ThePorts.ActivePort1.DataBits = 8;
ThePorts.ActivePort1.Parity = Parity.None;
ThePorts.ActivePort1.StopBits = StopBits.One;
ThePorts.ActivePort1.DataReceived += new SerialDataReceivedEventHandler(OurBackGroundSerialPortReceiver);
ThePorts.ActivePort1.Open(); // "Sometimes" Error hits here
}
Okay, I am now connecting without the semaphore timeout problem.
If anyone reading ever encounters the same thing, I hope that this procedure works for you; but no promises; hey, it's windows.
In my case this was Windows 7
I got a little hint from This page on eHow; not sure if that might help anyone or not.
So anyway, this was the simple twenty three step procedure that worked for me
Click on start button
Choose Control Panel
From Control Panel, choose Device Manger
From Device Manager, choose Universal Serial Bus Controllers
From Universal Serial Bus Controllers, click the little sideways triangle
I cannot predict what you'll see on your computer, but on mine I get a long drop-down list
Begin the investigation to figure out which one of these members of this list is the culprit...
On each member of the drop-down list, right-click on the name
A list will open, choose Properties
Guesswork time: using the various tabs near the top of the resulting window which opens, make a guess if this is the USB adapter driver which is choking your stuff with semaphore timeouts
Once you have made the proper guess, then close the USB Root Hub Properties window (but leave the Device Manager window open).
Physically disonnect anything and everything from that USB hub.
Unplug it.
Return your mouse pointer to that USB Root Hub in the list which you identified earlier.
Right click again
Choose Uninstall
Let Windows do its thing
Wait a little while
Power Down the whole computer if you have the time; some say this is required. I think I got away without it.
Plug the USB hub back into a USB connector on the PC
If the list in the device manager blinks and does a few flash-bulbs, it's okay.
Plug the BlueTooth connector back into the USB hub
Let windows do its thing some more
Within two minutes, I had a working COM port again, no semaphore timeouts.
Hope it works for anyone else who may be having a similar problem.
This error could also appear if you are having network latency or internet or local network problems. Bridged connections that have a failing counterpart may be the culprit as well.
I had this problem as well on two different Windows computers when communicating with a Arduino Leonardo. The reliable solution was:
Find the COM port in device manager and open the device properties.
Open the "Port Settings" tab, and click the advanced button.
There, uncheck the box "Use FIFO buffers (required 16550 compatible UART), and press OK.
Unfortunately, I don't know what this feature does, or how it affects this issue. After several PC restarts and a dozen device connection cycles, this is the only thing that reliably fixed the issue.
Too many big files all in one go. Windows barfs. Essentially the copying took too long because you asked too much of the computer and the file locking was locked too long and set a flag off, the flag is a semaphore error.
The computer stuffed itself and choked on it. I saw the RAM memory here get progressively filled with a Cache in RAM. Then when filled the subsystem ground to a halt with a semaphore error.
I have a workaround; copy or transfer fewer files not one humongous block. Break it down into sets of blocks and send across the files one at a time, maybe a few at a time, but not never the lot.
References:
https://appuals.com/how-to-fix-the-semaphore-timeout-period-has-expired-0x80070079/
https://www-01.ibm.com/support/docview.wss?uid=swg21094630
I had a similar problem which I solved by changing the Port Settings in the port driver (located in Ports in device manager) to fit the device I was using.
For me it was that wrong Bits per second value was set.
I was this problem with program RealTerm, then I entered into device manager and just disable the Bluetooth device connected into the port COM3.
The problem is with your cable not with your code or connection some cables are designed to send power only some are designed to send power and data we have to see those types of cables