I have some working code that captures the current desktop cyclically and using the code described at DirectX Screen Capture - Desktop Duplication API - limited frame rate of AcquireNextFrame / https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/DXGIDesktopDuplication
This works well except on one machine (where I unfortunately do not have physical access for detailed debugging but only get reports from users). On this machine when I call AcquireNextFrame() with a timeout value of 500, it repeatedly fails with an error code 0x887A0027 / DXGI_ERROR_WAIT_TIMEOUT. To make this clear: the call does not fail only a few times, it fails all the time, so AcquireNextFrame() never returns a result, no matter how often one
When I increase the timeout-value to 850, it fails with an error 0x887A0026 / DXGI_ERROR_ACCESS_LOST.
So...any idea what can cause these errors and how one can prevent it from happen?
Thanks!
The behavior is normal.
Windows does not normally render desktop at 60 Hz, that would be a waste of resources and electricity. DXGI_ERROR_WAIT_TIMEOUT simply means the computer is showing the same image as before. AcquireNextFrame returns S_OK and gives you another frame when some window visible on the desktop has updated something.
I think that one machine doesn’t run any programs which continuously updating GUI on the desktop being captured.
You have to workaround. For instance, maintain a copy of the desktop texture in your capturing app, when AcquireNextFrame returns S_OK update it with CopyResource, when it returns DXGI_ERROR_WAIT_TIMEOUT use the old desktop texture.
Related
We had to use CoFreeUnusedLibrariesEx for fixing a bug with heap not being cleared after using a MSXML library
Refer this link:
http://blogs.msdn.com/b/marcelolr/archive/2008/11/13/msxml-heaps-not-being-released.aspx
But this caused another issue with TTimers which takes while to show up and disappears when Delphi app is bounced and again shows after a while.
This app uses TTimers to schedule it's job like running a XML transform .
Here is the issue:
When TTimer.Enable is called it throws an error not enough Timer available.
I know this is a masked error and I would have to figure out how to get to the actual error.
This is a single threaded application with only one timer.
Here are the links I looked into
Most Common reason seems to be invalid windows handle
https://groups.google.com/forum/#!topic/borland.public.delphi.winapi/UrIskaFZggU
There are other threads that suggested that OS ran out of resources for TIMERS I'm not sure if that is relevant to me.
I'm Just trying to understand what is Interaction between CoFreeUnusedLibrariesEx and TTimers that it gradually some how robs it of resources and makes us bounce the app to get it working.
How do I go about solving this issue , I'm looking for some directions?
CoFreeUnusedLibrariesEx should not affect TTimers. But if loading and unloading a (buggy) dll leaks any user objects (this includes timers, window handles, ...) then I could imagine that you run out of user objects.
Use Windows Task Manager and configure it so it will show the "USER Objects" in the "Processes" tab. Then compare the number of user objects when you call CoFreeUnusedLibrariesEx and when you don't call CoFreeUnusedLibrariesEx.
I have an application written in Delphi 5, which runs fine on most (windows) computers.
However, occasionally the program begins to load (you can see it in task manager, uses about 2.5-3 MB of memory), but then stalls for a number of minutes, sometimes hours.
If you leave it long enough, the formshow event will eventually occur and the application window will pop up, but it seems like some other application or windows setting is preventing it from initially using all the memory it needs to run (approx. 35-40 MB).
Also, on some of my client's workstations, if they have MS Outlook running, they can close it and my application will pop up. Does anyone know what is going on here, and/or how to fix it?
Since nobody has given a better answer I'll take a stab at how to solve this:
There's something in your initialization that is locking it up somehow. Without seeing your code I do not know what it is so I'll only address how to go about finding it:
You need to log what you accomplish during startup. If you have any kind of screen showing I find the window title useful for this but it sounds like you don't--that means you need to write the log to a file. Let it get lost, kill the task and see where it got.
Note that this means you need to cleanly write your data despite an abnormal program termination. How to go about this:
A) Append, write your line, close.
B) Write your line, then flush the file handle.
C) Initially write your file to consist of a large number of blanks--ensure this is larger than the actual log will be. Write your line. In case of abnormal termination it will retain the original larger file size.
I would write a timestamp on every log item so you can see if it's just processing something too slowly.
If examining the log shows you where the problem is, fine. If, as usually happens, it's not enough you put a bunch more logging between the last item that did get logged and the next one that didn't--I've been known to log every line when hunting a cryptic problem that only happened on someone else's system.
If finding the line isn't enough to pinpoint the problem also dump the value of relevant variables.
Finally, if such intense scrutiny makes the bug go away start looking for an uninitialized variable. (While a memory stomp is also an option I doubt it's the culprit here.)
I have a PIC32MX340F512 board developed by another company for us, The board has a DS1338 RTCC and 24LC32A eeprom, and display unit on an I2C bus, on this bus i included a TSL2561 I2C light sensor, i wrote code in c to poll the light sensor continously , when the light sensor reaches a certain level i save the time and date and light sensor value on SD card. This all works fine but if i leave the system without exposure to light inside tunnel where incident light on one end of the tunnel is ought to be monitored the system becomes unresponsive no matter how much amount of light you apply and then if i switch power off and back on again everything starts to work normal. i am a one man development team and have been trying to find out the problem for months, i activated the watchdog timer to prevent the system from hanging but the problem still persisted. i then decided to find out if the problem is with the sensor by including a push button to activate light measurement but still when 4-5 hours elapse the PIC cant even detect a change in the the input pin. Under the impression that a hardware reset overrides anything going on i included a reset button and it also works ok for the first few hours after that the PIC doesn't seem to be responding to anything including a reset. I was getting convinced that there is nothing wrong with the firmware but also with all this happening the display unit (pic16f1933 and lcd) on the I2C shares power with the main unit and doesn't seem to be affected as it alternates between different messages constantly Does anybody have an idea what could be wrong (hardware/firmware or my sensor). I am using a 24v DC power supply purchased seperately. The PIC seems to go into a deep sleep although i dd not implement any kind of SLEEP mode in my code. Nb We use the same board for many other projects and i haven't come across such a problem . Thanks in advance.
I think you need to (if you haven't already) explore the wonderful world of in-circuit-debugging (such as with the ICD3 or PICkit 2/3). It allows you to run the processor in a special mode that lets you pause execution, see exactly which line of code is being executed, inspect variable values, and step through the code to see which parts are running and not running, or see exactly where execution takes a wrong turn. If the problem takes hours to reproduce, that's okay. You can just leave it overnight running in debug mode and hopefully it will be locked-up or 'sleeping' in the morning. At this point, you will be able to pause the processor and poke around to see if you got caught in some kind of infinite loop or something. This is often the only way to dig inside a running piece of code to see why things aren't working as you expect. But as you say, those bugs that take hours or days to manifest are the trickiest. Good luck!
It sounds like you can break up your design into two main parts, sd card interfacing, reading the rtc and reading the light sensor. If it were me I would upload a version of the code that mimics reading the light sensor but only returns fake data and see if that cures the problem. Additionally do the same with the other two modules separately and see if any of the three versions of your project not show this problem. From there just keep narrowing it down until you find the block of code thats causing problems.
if Two or more versions of your debug code show the same problem then my guess is it has to do with one of the communication protocols. I had a problem with a Pic32 silicon version blocking when using the DMA in conjunction with the SPI peripherals. So I would suggest checking the errata for your chip.
If you still cant find the problem, my only suggestion would be to check for memory leaks or arrays that are growing into reserved memory.
Hope that helps, good luck!
I've written some code, which currently consists of two windows to show different stages of some processing algorithm. Quite simply, I've created the two windows with cv::namedWindow(), and I'm displaying the cv::Mat with cv::imshow(). I'm having an issue where every now and again, randomly (but not always), cv::imshow() refuses to update the two windows. The program hasn't hung, and I can see that it is still working and processing the incoming frames (as I'm printing stuff into the terminal to show this), it's just that the windows aren't showing the new frames. I've included cv::waitKey(2) after each call to cv::imshow(), however this doesn't help.
This is very annoying, and I can't seem to find anything online. This doesn't always happen, but it does more often than not. Sometimes it takes a few minutes, sometimes it takes a few seconds.
I'm using Ubuntu 12.04 (and Ubuntu 11.10 - this happens on both of my machines with two different cameras) with OpenCV 2.3.1.
One way I've been able to get around that issue is by using
cv::destroyWindow()
after calling a window. This works well if you're just showing a sequence of images, but not so well if you're showing video.
I have a delphi app that takes snapshots from a webcam at 1 sec intervals. On the development PC it goes fine, but on the target platform (Atom-based tablet PC running embedded Windows 7 with a different camera) it is extremely flaky. After a reboot and the first time the app is run, it normally manages to initialise the webcam OK and get regular frames from it, but the next time the app is run, it fails to locate the webcam driver, and also pops up a dialog asking me to specify the video source, presumably because it can't find one..
My question: I'm sure this is related to video capture API calls not being in the right order or something, but is there a tool (like wireshark) that will enable me to sniff the API calls, so I can compare what is happening on the embedded Windows 7 system to the XP development system that works?
I am using the following calls/messages:
Initialisation:
capCreateCaptureWindow
WM_CAP_DRIVER_CONNECT
WM_CAP_SET_PREVIEW (false)
WM_CAP_SET_VIDEOFORMAT (as camera after boot is in format I can't handle)
WM_CAP_GET_VIDEOFORMAT
On 1 sec timer:
WM_CAP_SET_CALLBACK_FRAME
WM_CAP_GRAB_FRAME_NOSTOP
On callback:
WM_CAP_SET_CALLBACK_FRAME (nil)
On finish:
WM_CAP_ABORT
WM_CAP_STOP
WM_CAP_DRIVER_DISCONNECT
The first step is a lot easier: Did you make absolutely sure you have the same driver?
It might also be that the sequence of detect - start acquisition is too fast for this slow system. See if introducing a few secs sleep inbetween helps