My office recently transitioned from running Windows 7 to using remote desktop sessions running on Windows Server 2012. Some VBA macros I was using include calls to the "Beep" function in the Windows API, which I used as an audio alert that execution had completed. This is the version of "Beep" that takes in a frequency parameter and a duration parameter, and plays a beep of that frequency in Hz for that duration in ms. On the new system, however, no sound is played, and there is no delay after calls to the function. Did Microsoft remove the Beep function in Server 2012?
EDIT: this is a different question than the linked discussion about Beep in Windows 7. I was previously using this code on Windows 7 without any problems. I have checked that my computer's speakers are turned on, that they are plugged in, and that the system volume is not muted. The behavior here is that Beep() is being treated as a null; nothing happens when it is executed. If the sound were simply muted, the code would at least delay until the indicated number of milliseconds had elapsed; instead, Beep() is skipped like it's not there at all in my code. Take, for example, the following code:
Sub beepTest()
k = Beep(523, 5000)
MsgBox("All Done!")
End Sub
On the old Windows 7 system, the computer would play a tone over the plugged in speakers for 5 seconds, then pop up with the message box. When running inside the Server 2012 RDP, however, the call to Beep() is essentially ignored, and the message box appears instantaneously, without a 5 second delay. This means that it can not be just an unplugged or muted sound device; if it were, there would be no sound audible, but there would still be a delay, similar to calling the Sleep() function. I wanted to know whether Microsoft had possibly removed support for this API in Server 2012, which would explain why my code isn't working as intended.
Related
I have come across a Lenovo IdeaCentre A540-24ICB system with a scheduled task that wakes the computer to start my application and it seems to start but the system goes back to sleep right away. Sometimes it appears to not start (or goes to sleep so fast nothing is logged yet) so I checked the Windows power sleep options to ensure "Allow wake timers" was enabled but it didn't exist! Searching online I found a registry entry to add to have it show up in the power options and then ensured it's was enabled. However, didn't make a difference.
I have to use the mouse/keyboard for the computer to wake long enough to run the application (it will start where it left off). The application has been used for years and waking and running has worked. It already tells the system to not go to sleep through the api call in the main processing thread (which could take a fraction of a second to get to):
SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED);
I thought that API was enough to prevent system from going to sleep? As mentioned, it has worked for years. It's just this new Lenovo system or the Win10 installed with it doesn't seem to honor it? Is there some other API call that needs to be called? or any checks / fix the app should do to ensure the SetThreadExecutionState() will work?
TIA!!
Summary
When putting the monitor in sleep mode in Windows 10, Windows seems to execute some tasks that don't get executed with the screen on.
This is interfering with our software, and we need to get rid of it.
Ful story
For a hardware device with a touch screen, I need to be able to turn off the touch screen when it's not in use, for durability reasons. Windows has a message that you can send to turn it off, SC_MONITORPOWER. More specifically:
SendMessage(hwnd, WM_SYSCOMMAND, SC_MONITORPOWER, 2);
This works fine, but when the screen is off, Windows is apparently sometimes performing some tasks that it doesn't do when the screen is on. We are careful to never write anything to the screen in this situation (that causes huge problems when the screen is off, in fact just having a blinking cursor in a DOS box is using up half a core when the screen is off).
Our software requires a callback to be executed every 0.25 ms. We have turned nearly every task, service and several other things in Windows off, and with the screen on, I can run our software for days without ever missing a callback. But with the screen off I get hiccups. The callback already runs at the highest possible priority.
So there is apparently something that we missed when we turned all services and tasks off. There appear to be 2 causes of hiccups:
One happens once every 10-30 hours or so (not sure of the exact time, it seems to vary). But it always happens 5 times, with EXACTLY 5 minutes (at most a few milliseconds off) in between (so in total it happens 5 times in a 25 minute period).
Beside this, we get a single hiccup typically every 4-10 hours, but the time between occurrences doesn't seem to be very constant so there could also be multiple causes.
I'm a bit at a loss here, and running analysis software can easily interfere with our own software, making it harder to detect when these hiccups really occur and when they are caused by running the analysis software.
Interestingly, I have seen this 5-times-every-5-minutes thing also on a completely different system (different hardware, different OS version), when recording audio in Adobe Audition. Audition misses pieces of audio every 5 minutes in this case, and I think it also only happens when the monitor is in sleep mode and you're not logged in remotely.
We have already tried to turn the touch screen off using direct monitor commands like Nircmd does, and it doesn't support those. My guess is that the SC_MONITORPOWER message is triggering more things in Windows, and if we can turn them off, that would fix our problem. Any ideas?
System
Intel i5-8700 with 6 cores, Windows LTSB, no extra software installed except our own.
Never mind, problem solved. It was not an extra task that was being started, it was one of the existing Windows processes that for some reason only causes issues when the display is off. Since killing them is not an option (Windows will just restart them), I've suspended the following processes, and the culprit is one of these (I don't know which one yet):
sihost.exe
igfxEM.exe (I very much suspect this one)
RuntimeBroker.exe
dllhost.exe
taskhostw.exe
explorer.exe
I have to continue testing a bit longer to be absolutely certain, but so far with these tasks all suspended I've not seen a missed callback in the last 38 hours. I don't know yet if there are any drawbacks to suspending all these things, so I'll try to find the cause(s) and suspend only that/those.
I am working on a Windows 10 application that plays audio in the background. What I would like to be able to do is allow the computer to still go in to Sleep Mode while the audio is playing (as in, Power & Sleep Settings, Sleep after XX minutes). And by this, I mean stop playing the audio and go to Sleep (not continue playing while in Sleep). Is this even possible? Searching online hasn't been fruitful, as I can pretty much only find information on how to prevent Sleep, not enable it.
Running powercfg.exe /requests shows the audio playback is indeed preventing sleep:
SYSTEM:
[DRIVER] Realtek High Definition Audio (...)
An audio stream is currently in use.
I am currently using the IAudioClient and IAudioRenderClient interfaces for playback, via client->Start(), renderClient->GetBuffer(). I could switch to a different API if necessary. However, whatever I use needs to allow other applications (VLC, YouTube, Windows sounds, etc.) to play audio as normal at the same time.
My application is always running on the system I'm using it on, and I simply want the system to be able to go to Sleep at the set system timeout. I also need to apply this exception to my application only - if other applications are playing audio that would prevent Sleep, the system should not Sleep.
Are there any Windows API calls that can make Windows ignore my application playing audio and still let the system go into Sleep Mode?
What you are asking for is not possible today. When the system goes to sleep, it essentially means that the processors in your system stops executing any instructions and powers down. Although this is not like shutting down the system, it is very close to it. All the devices connected to the processors are also powered down to save the battery/power consumption.
We are completing a generic service-bus implementation on C, with clients for C#, Delphi, PL/SQL and PHP.
The library works great, we have awesome performance for our bus unless the MongoDB database is running on Windows (tested on 2008 R2, 2003 and 7) and there's no other "special" program running.
Out test do the following:
Program A sends a message on a capped collection
Program B tails on the message queue collection and "wakes up" when message appear using a cursor with awaitData param set to true
When Program B wakes up, prepares a messsage and sends a response to Program A inserting a document on a specific collection by Program A
Program A was already waiting on the second "response" collection and gets awaken when Program B (the producer) sent the response back
Loop ends there
Our testing program counts the loop and reports performance on a console application compiled with Visual Studio 2010.
We run this everything on one machine, or using a different machine for MongoDB and running consumer and producer on the same machine.
We run this on Windows 2008R2, Windows 2003 and Windows 7.
For 2008R2 we used the special mongo build for that OS, while for 2003 and 7 we used the "legacy" 64 bits build.
In a clean OS, with no programs running, our test performs about 32-50 roundtrips per second, which is a lousy performance compared to the "good" results we get when everything goes full speed.
Now, here comes the strange thing:
When starting certain application on the same machine where the mongo database runs, our tests speed up to about 450/sec (when running over loopback everything on the same machine) to about 300/sec when consumer and producer run on one machine, and mongodb in another machine going over the network.
The reason we never noticed this problem consistently before was because pretty much all the time we had in our development vms Visual Studio open, and Visual Studio is a program that acts as a "mongodb accelerator" (I know this sounds ridiculous, please don't bash me on this statement).
At first we noticed this issue "randomly" essentially when running our tests without VS open. So we tend to blame it on the underlying SAN where vmware runs, or the vm hosts, or cosmic rays or the NSA snooping on our program.
This was until we figured out finally the correlation between VS open at the same time while we were running tests, and narrowed down to the following:
MongoDB running on a Windows system (as console OR as service), virtual or physical versions 2008R2, 2003 or 7 will run slow a pattern of receiving data on a capped collection and waking up a tailing cursor then sending a response back to the consumer on another capped collection in the same way unless you simply start a program such as Visual Studio, Delphi XE4, Google Chrome browser, CrystalDiskMark disk I/O testing program (other program may speed up Mongo too). Then mongodb speeds up on full order of magnitude the pattern mentioned before.
We could not find exactly what these programs have in common that may cause the issue.
At this point we are stunned by the issue, I even reviewed the MongoDB code used for tailable cursor, but didn't find anything that smells as potentially causing a problem. The code pretty much spins for a max of 4 seconds waiting for data to appear, besides the suspicious "sleep" call on every loop, there was nothing else eye catching.
Is it possible that certain programs end up causing Sleep() Windows API call to behave differently? And that makes mongo do this operations on tailable cursor slower??
We think something is indeed "slowing down" because also the CPU utilization profiles goes down, like mongodb is literally "waiting" for something when it's running slow.
I know this pattern works fine on unix/linux based systems, I tried the same codebase on a Mac with no issues, so this horribly smells as a Windows issue.
Anyone else experienced a similar issue out there?
Found the source of the problem.
MongoDB calls straight Sleep() Windows API function, even for Sleep times lesser than 15ms.
Because of the default Windows minimum resolution, anything less than that (at least on Windows 2008 R2, Windows 2003 and Windows 7) will sleep for at least 15ms no matter what.
Simple solution in MongoDb is updating time_support.cpp from this:
void sleepmillis(long long s) {
fassert(16228, s <= 0xffffffff );
Sleep((DWORD) s);
}
to:
extern "C" unsigned int __stdcall timeBeginPeriod( unsigned int ms );
extern "C" unsigned int __stdcall timeEndPeriod( unsigned int ms );
// Notice bellow the arbitrary nature of 50ms set as the "minimum" timer resolution
// There seems to be no complete agreement on that *is* the default timer resolution in Windows.
// To be on the "safe side" let's use 50ms
#define BELLOW_WINDOWS_MIN_RESOLUTION(s)(s > 0 && s < 50)
void sleepmillis(long long s) {
fassert(16228, s <= 0xffffffff );
// When our waiting period falls bellow Windows min resolution, let's set resolution
// to 1 ms. Note that this change may effect all kernel scheduler thread operations.
// Apparently this changes the Windows kernel "quantum" length
// see http://msdn.microsoft.com/en-us/library/windows/desktop/dd757624(v=vs.85).aspx
// Applications such as Google Chrome seem to do this during the life of Chrome, that's why
// running apps which do this "accelerate" certain mongo operations that depending on proper
// Sleep() resolution on Windows
if(BELLOW_WINDOWS_MIN_RESOLUTION(s)) timeBeginPeriod(1);
Sleep((DWORD) s);
if(BELLOW_WINDOWS_MIN_RESOLUTION(s)) timeEndPeriod(1);
}
I'd like to attach a debugger to a base csp minidriver on windows 7.
Which process hosts the driver .dll? Is it just another WUDFHost.exe ?
Can I attach a user-mode debugger to that process?
At least when using certutil.exe the .dll is loaded "directly" into the process.
In Visual Studio one can set certutil.exe as the command in the Debugging panel and then step into the minidriver.dll's code and thereby test how certutil tries to access the smartcard.
I did simple stupid logging instead of debuging of my minidriver.
Testing your minidriver with certutil is easy:
certutil.exe -SCInfo
The idea of debugging a minidriver is bias.
For windows 10 there is a 5 second timeout to operate with a card. If you don't poll the card for 5 second you get your card reset by the operating system.
Here is how the error looks:
The card in Smart Card Reader 'Generic EMV Smartcard Reader 0' has been reset because an application held an exclusive transaction
on the card for 5 seconds without activity. If this error persists,
the application may not be functioning correctly.
Here is what Microsoft says about it:
Smart card transactions On Windows Server 2012, Windows 8, and Windows
RT, if a transaction is held on the card for more than 5 seconds with
no operations happening on the card, the card is reset. This is a
change from the behavior in previous releases.
For healthy debugging you have to introduce a separate thread that polls your card status with SCardStatus or SCardGetAttrib as Gemalto does
To avoid the system resetting the smart card after the 5-second
timeout, Gemalto recommends you regularly call a transparent function
like SCardStatus or SCardGetAttrib, using a timer, after calling
SCardBeginTransaction. This change also applies to Windows 8, RT and
Server 2012 systems.