We Keep Coding

Shortcut to "Scan new hardware" on Windows?

My computer suffers from the dreaded no sound upon wake-up from sleep (on my HDMI connection) on Windows 10 using the Integrated graphics, Intel HD Graphics 530. I don't know the exact reason for why this is happening, but I understand it as the handshake between monitor and computer is not properly established after wakeup, and thus the audio device is not recognized.
This is confirmed by viewing the available sound devices in Windows.
Apparently this is a common problem, and I tried the following solutions:
Pin-19 trick: Which consist of blocking pin 19, which prevents detection of when monitor goes to sleep. This did not work for me, and I got just a blank screen.
EDID trick: Which involves passing the missing information always on-demand so it doesn't have to try to get the data from the handshake.
Neither solution worked, and the only consistent thing I found working was going to Device Manager, and right clicking the computer, and choosing "Scan for hardware changes".
Is there a way to replicate that with a Windows shortcut on the desktop?
Perhaps a tiny C# program that gets executed every time it wakes up from sleep? Anyone with some Windows programming skills know how to do this?

It's possible to subscribe to an event that's fired when the computer is resuming from sleep.
SystemEvents.PowerModeChanged += OnPowerChange;
Inside the event you can check for the PowerMode and run code depending on which one it is. Resume is the one that tells you the computer is waking up from sleep.
private void OnPowerChange(object s, PowerModeChangedEventArgs e)
{
switch ( e.Mode )
{
case PowerModes.Resume:
ScanForHardwareChanges(); // Your own method
break;
// Possibly hand other power modes too
}
}
Regarding your question about running the hardware scan programmatically, here's a thread that has multiple examples and links that'll help you:
Is there an API call to start a scan for hardware devices?

USB-Serial Port stops working without any reason

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.

"The semaphore timeout period has expired" error for USB connection

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

Diagnose communication problems with a Zaber device

When I write software to control Zaber devices, I sometimes get strange behaviour that I don't understand. Usually it's caused by bugs in my script or other software, and sometimes it's a hardware problem like a loose connection on the serial port.
How can I see exactly what commands my software is sending and how the device is responding? I'd like a kind of log file that I can search through to see what's causing the errors.
Most often, I'm writing scripts in Zaber Console using C#, but I also write LabVIEW VIs using the Zaber instrument driver.

There are several techniques to see the raw data being sent to and received from Zaber devices. Some are restricted to certain operating systems, others only work with some software. Most of the options involve looking at the raw data, so look in the user manual for details about the message format, and a list of command numbers.
Below, I'll try to list a few options and tell you when they are available.
Zaber Console Log Window
Only in Zaber Console, only on Windows.
This is the easiest technique if you are using Zaber Console scripts or plug ins. The window in the top-right corner records all the requests and responses for you. You might find it easier to track down the problem if you clear the window just before the problem occurs, and stop the script right after. One shortcoming is that some corrupted messages are not shown, you just see a partial packet timeout error. If the messages you want are getting scrolled off the top, change the log size on the advanced tab.
Portmon
Only on 32-bit Windows.
Portmon was a great tool, and I'm sad that it never got upgraded to 64-bit Windows. If you're still running a 32-bit version of Windows, it's worth trying. I found that the latest version 3.03 didn't work for me, but 3.02 still does. If the official version doesn't work, then searching for "portmon 3.02" will usually find some site that carries the old version.
In version 3.02, open the Computer menu and choose Connect Local.
From the Capture menu, choose Ports: COM1, or whatever serial port you want to connect to. Make sure your software is currently closed, or Portmon won't be able to connect to the serial port. Sometimes after using Portmon, you have to restart the computer to make it release the serial port.
From the Edit menu, choose Filter/Highlight... and set the Include to be IRP_MJ_READ;IRP_MJ_WRITE
On the Options menu, enable Show Hex and Clock Time.
Try sending some commands from your software, and then look at the Portmon window. You should see something like this after you widen the Other column.
In the screenshot you can see two commands being sent (1 block of 6 bytes for each command), and two responses coming back (6 blocks of 1 byte for each response). Remember that the display is using hexadecimal numbers, so the first command is 14 hexadecimal or 20 decimal (move absolute).
HHD Serial Monitor
The best replacement I've found for Portmon is HHD Serial Monitor. It's not free, but it has a trial period, and the license is pretty cheap. I think it might be more powerful than Portmon, but it's not as easy to use.
Here are the settings I found to be useful for logging Zaber device commands. After installing and starting the Device Monitoring Studio, I clicked on the serial port I want to monitor in the list of ports. That opens a list of available views, and I double click on Request View. On the right-hand side, I click the Start button. That opens the request view, and I click on the Complete tab.
Now when I send some commands to the device, I see read and write requests with hexadecimal and text display of the data. Here's the equivalent of the Portmon screenshot above.
Again, the first command is 14 hexadecimal or 20 decimal (move absolute).
NI Spy or NI I/O Trace
Available with LabVIEW
This option isn't as easy to read, but it comes with LabVIEW, and you can read the documentation on how to start it. Here's a screenshot of the NI Spy tool. I think it came with older versions of LabVIEW.

Trick Windows To See Second Monitor

is there anyway to trick windows into thinking that a second monitor is connected to the computer, even if there isnt one?
Example:
Laptop also has an external screen connected into it. The external screen is the primary screen.
When the screen is disconnected the laptop becomes primary even if the external screen is reconnected. Is there a way to trick windows into thinking that the monitor is always there? and not revert to the laptop screen as primary screen?
The way I am thinking it could work is some kind of low level driver? But I wouldnt have a clue where to start

For work, I actually had the same situation -- on an embedded PC, we needed a second monitor to always be available.
I put a considerable amount of time into researching it, but I wasn't able to find any solution other than with hardware.
If you have a VGA port (or DVI-I), you're in luck. You can find directions on how to fake that with a couple resistors (here's one set of directions).
Ultimately, for my project, we only had a DVI-D port available. I had to come up with a microcontroller solution to send "fake" monitor signals (via I2C) to the PC. I can't go into much more specific detail than that, unfortunately.