.jpg from ScreenCapture is blank

pgriffin · Post by **pgriffin** » Mon Mar 27, 2006 10:27 pm

I have a load test running on 40 Remote desktops on the console of a TermServer. this script (if it encounters unexpected pixel values) takes a screen shot with ScreenCapture, then ends. When I go back to view the logs file I have the script create, and then compare that file (which contains the last task attempted) I find the corresponding JPEG is blank. I have the script name the respective jpeg's based on the log-on user and hour/min/sec....so test1091525.jpg would be user "test1", 09 is the hour, 15 is the minute, 25 seconds.....they are definitely unique names, but still I'm getting blanks...

When i run only one (or very few) session then I get good screencapture results....

is there some piece of Screencapture which might cause it to become "confused" if used in this manner?

btw, I use one copy of the script (.exe) which is accessible by all the remote users...

Hope my explanation is not too confusing.... I'll gladly clarify as needed...

thanks,

Paul

JRL · Post by **JRL** » Tue Mar 28, 2006 5:42 am

Paul,
I have no experience doing what you're doing but that won't stop me asking a couple of questions.

What does the SCREENCAP_RESULT variable tell you?

Are you saying that test1091525.jpg is created and is 0 bytes in size?

On my network calling from a Win2000 file server, I have to avoid having users run executables directly from the server. If one user has the exe in use, no other user can run it. I have no experience with Terminal Server but are you sure you're not running into file access problems?

I had a situation once where I was creating zero byte files and discovered I was defining the two sets of coordinates (through variables) as equals, so I was defining a zero pixel sized box. ScreenCapture>10,10,10,10,test.jpg will create a zero byte file.

Any help there?
Dick

Post by **Marcus Tettmar** » Tue Mar 28, 2006 7:50 am

Paul,

I've sent you a version of msched with an extra error check in ScreenCapture to see if it gives us some clues.

pgriffin · Post by **pgriffin** » Tue Mar 28, 2006 3:14 pm

Thanks for input, guys. Here is my update. To answer Dick's question, the files are 13 KB, no idea why..they are totally blank.

I did originally write the ScreenCapture to also record SCREENCAP_RESULT (which was never > 0)..

Marcus, the new version I received did not record a different SCREENCAP_RESULT...

Maybe some more ramblings from me about my set up....

My test uses different users depending on how many desktops I want to test. test1 through test100 (at the moment)....usually only testing up to test40.

I have tried using 20 separate copies of the .exe....test1.exe, test2.exe and so on....same result.

The test itself is a very simple click-through of a Portal Application...loads a few graphics, waits for the pixels, clicks the next tab, opens a popup, etc...nothing heavy.

Seems to me that ScreenCapture might not care which session from which it is being called. Any way to send session specific calls? As it is the same API being called in each of the 40 or so cases....

As always, thanks for your help.

Paul

Post by **Marcus Tettmar** » Tue Mar 28, 2006 4:07 pm

Paul,

Are any of the terminal services client sessions ever minimized? If you minimize a terminal services or remote desktop session the desktop is no longer interactive. When a termserv session is minimized it will stop responding to keyboard and mouse events because it ceases to be an interactive window station. In addition screen painting will cease until the session is restored.

Therefore, ScreenCapture would probably get a blank image when the sessions are minimized.

Wait a sec, let me try something .....

Yes, you get the same effect if you do a ScreenCapture while Windows is locked. Makes sense. The user's desktop window is inactive and invisible when Windows is locked. So ScreenCapture gets a blank image. There is no graphic - the device context is empty. A Terminal Services session that is minimized is just like a regular locked Windows session.

So my guess is that is what is causing your issue. If I'm right you will just need to make sure none of the sessions are minimized .....

.... either that or too many sessions has the same effect - perhaps the client can only cope with so many sessions and after a certain amount the rest have to be effectively suspended and go inactive, until you make it the active session.

That last bit is speculation on my part - only Microsoft could tell you if I'm right or not. But it kinda makes sense.

pgriffin · Post by **pgriffin** » Tue Mar 28, 2006 4:14 pm

That makes sense. I made change to a controlling script to minimize all the windows after starting the testing scripts. My thinking was that minimizing would prevent me to interfering with the scripts....should have just used BlockInput.....which I will now do...

thanks for the Brain Cycles....

I'll post the result of removing the WindowAction line to minimize.