We Keep Coding

Is there a way to keep internet connections / sockets open after iOS forces app into sleep mode?

I'm developing a Xamarin app that uses location background modes to keep itself awake in the background, scan and report on iBeacons in its range over AMQP, and also make HTTPS requests to a log server.
This all works great, until a sustained period of time where the GPS location does not change and there are no changes to the radio frequency environment (i.e. no new iBeacons introduced, none taken away).
It appears that iOS puts the app into sleep mode (it's a slightly different sort of sleep mode to normal, as background modes are involved, so I don't see an OS callback for this). Moving the phone, or introducing new iBeacons wakes the phone up, but sometimes the app is no longer able to access the internet, using objects that were created before the app was sent to sleep. It appears as if the kernel is closing sockets.
Any ideas as to how I could diagnose this issue more effectively, or suggestions to how I can keep these sockets open, would be most appreciated.
Thank you for reading!

Semaphore timeout period has expired error [duplicate]

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

Why does my Blink based browser play hide and seek?

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

Automating cursor movements, mouse clicks and keyboard inputs in not helping to show that user is present on system

I have a software installed on my system which basically peeks my activity during working hours. It send a report saying how much time i was away from my system etc.
Since i m .net c# developer hence trying to break this system through my programming skills.
I have basically written up a windows form application which opens up an notepad for me and start typing some random characters into it. simultaneously it also performs some random clicks and moves the mouse cursor to give a feel that some one is on system and working even when i am not :)
I also use "SetThreadExecutionState" Pinvoke calls to keep system awake.I have also observed the User idle time and last interactivity time through "GetLastInputInfo" PInvoke system call while my mouse/keyboard are in automation process and it is also fine.
But this is not working for me. It works perfectly till 5 mins and then somehow it detects that user is not present on system.
any suggestions for the same.

Get a decompiler, crack-open the spying application and see how it is working inside. Only knowing the internal workings, you can create a "workable" any-spying program. But I would not bother with emulation of the activity, but rather spoof the way it reports to the server.
However, depending on where you live, it might be illegal to do these things and I would not recommend cheating your employer. And if spying gets on your nerves I'd also suggest to brush up your CV and start searching for a new job.

.Net Application extrem slow. After killing svchost.exe it runs again fast. Any idea?

I've a C# .Net 3.5 Application (x86) running on Windows7 x64.
For any reason after a few days or weeks the App runs extremly slow.
All other Apps runs normal (also another C# .Net 3.5 Application (x86)).
After killing a few svchost.exe the Application runs normal again. Rebooting without killing svchost.exe also doesn't help. Probably Windows saves the state of svchost.exe. If I logoff the user and login again it also works again, without killing the svchost. On logoff the svchost is probably cleared.
Does anybody have an idea how to solve the problem?
Greets
Wowa
EDIT:
The Main-Form is just an MDI-Container with a Treeview on the left-side with static nodes.
The Application checks on start for Updates via networkpath (checks files creationdate), but this can't be the problem, because all other PC works without a problem.
After the Update every MDI-child-form takes 1-2 minutes to start, even a empty form.
EDIT:
Sorry, i've forgot, that the updating is no more done by this application, but by another, which has nothing to do with the app which runs slow.
The app which updates the slow app runs normal. It only updates the slow app if it isn't running.
But the slow App removes files in the local Temp-path. System.IO.File.Delete()

Without any details or code as to how exactly your application checks for updates at startup, I'm going to guess that it's doing it on the UI thread (main thread), and blocking your application while doing it.
You mentioned that it's checking for updates via networkpath, I'm going to assume that you mean network share, in which case this might be the reason one of the svchost processes is acting up. Get Process Explorer, and use it to determine exactly which services are started by the offending svchost (by looking at the hint, or the Services tab in the process properties):

Perhaps it could be related to virus scanning software. If you have it installed, disable it and try the process again.

Same thing has been weighing us down.
Acrobat InDesign CS5 ME ver. (x86 app)
We have tried and tried again (Win7 64; 2gb; 1gb video card). I have noticed scvhost # 50,000 sitting in Taskmanager; killed it, but comes back. We haven't upgraded yet because of this.
We run the same app on XP-32, and also have some trouble, but that i more likely because of only 128mb video memory (2 P4 chips, 4gb mem).
I have peeked in ProExp but didn't know HOW to look. Thanks for the tip.
Hey, I'm a plain guy, not a pro programmer.