CmdBkg - use bitmap as background to console window

[misol101]

If you don't use "FreeConsole()", then this could result in a console that doesn't close, because there is one process (== "this one") attached to it.

Ah, excellent! That actually solved the problem I had in the other version I wrote (cmdbkg2) of this app, a console app that creates a GUI, then starts a separate process to take care of it. (It has the benefit that "start" is not needed to run it in a script, unlike cmdbkg). But I was getting a console hang on running "exit". Calling FreeConsole() from the new process takes care of that problem!

[aGerman]

Yes penpen's solution is by far the easiest for a console window

Steffen

[Compo]

Just some info on a bug with your updated version.

I've been away from a PC for around 24 hours and it's been in sleep mode with a backgrounded console window open, but minimised. When I restored it from minimized today the background has decided to not return with it. I just have a transparent console window now instead. (I tried a desktop refresh but that made no difference).
http://imgur.com/a/iedBL

[aGerman]

The background is a separate window that runs in its own process (cmdbkg.exe). Whenever that happens again please open the Task Manager and check if cmdbkg.exe is still running or if it was terminated for whatever reason.

Steffen

[Compo]

I can confirm that the process is not running, and assure you that I have not closed it seperately from the running console window.

[aGerman]

That's strange. Normally the sleep mode shouldn't terminate a process

[Compo]

I even checked to see if the cmd.exe parent process still had a handle on it but unfortunately not.
This was all I could find under the parent process' ID:

Code: Select all

Caption=cmd.exe
CommandLine="C:\Windows\System32\cmd.exe" /K "Start "" "C:\Users\Compo\cmdbkg" "C:\Users\Compo\prompt.bmp" 25"
CreationClassName=Win32_Process
CreationDate=20160916090221.430848+060
CSCreationClassName=Win32_ComputerSystem
CSName=PHENOMII-X4-955
Description=cmd.exe
ExecutablePath=C:\Windows\System32\cmd.exe
ExecutionState=
Handle=9372
HandleCount=108
InstallDate=
KernelModeTime=780005
MaximumWorkingSetSize=1380
MinimumWorkingSetSize=200
Name=cmd.exe
OSCreationClassName=Win32_OperatingSystem
OSName=Microsoft Windows 7 Professional |C:\Windows|\Device\Harddisk0\Partition2
OtherOperationCount=1701
OtherTransferCount=18066
PageFaults=5557
PageFileUsage=4256
ParentProcessId=1832
PeakPageFileUsage=8512
PeakVirtualSize=88817664
PeakWorkingSetSize=9852
Priority=8
PrivatePageCount=4358144
ProcessId=9372
QuotaNonPagedPoolUsage=10
QuotaPagedPoolUsage=147
QuotaPeakNonPagedPoolUsage=13
QuotaPeakPagedPoolUsage=161
ReadOperationCount=16
ReadTransferCount=2381
SessionId=1
Status=
TerminationDate=
ThreadCount=2
UserModeTime=156001
VirtualSize=76865536
WindowsVersion=6.1.7601
WorkingSetSize=9252864
WriteOperationCount=0
WriteTransferCount=0

[aGerman]

It's the other way around. As you said the cmd.exe process is the parent of cmdbkg.exe. Once it was started cmdbkg.exe determines the window handle of its parent in order to make it transparent, get its dimensions, and follow its position. The cmd.exe process never held a handle of cmdbkg.exe.

Lets wait for misol101. Maybe he knows why the process was terminated. Could have something to do with his polling algorithm ...

[misol101]

There are basically 4 reasons the cmdbkg.exe process would quit.

1. The console window it's tracking no longer exists (has been closed). A minimized window should be ok.
2. A refresh of the window (the image) was started, but the image could not be loaded (i.e. the image was renamed/moved)
3. The title of the attached console window changed name to "Kill" (very unlikely in this case )
4. Some other memory violation crash or whatnot, but in that case Windows should pop up an alert about that, I assume..

I haven't even tried what normally happens in sleep mode, to be honest. I'll try it out.

I also did have some initial problems with minimizing earlier, basically the window gets so small that the image width and height became negative. It's working for me now, but if you haven't already done so, please try minimizing and then restoring the console window a few times to see that it works.

It's also possible the image reading funtion fails for some other unknown reason: (i.e CreateCompatibleDC/GetDC fails). But I don't know why that would happen

[misol101]

Ok, so somewhat confusingly, the image is there when I return from sleep mode (doesn't matter if minimized or not). However, if I select "Change User", then the background image window is dead when I return (I didn't actually change user, just returned back to the one I had)... (again, doesn't matter if it was minimized or not)

I'm guessing that at some point, the IsWindow() API returns false, but haven't checked it yet.

EDIT: I'm also guessing I might need an API/hook to determine if the machine is going into sleep/logging out/changing user etc.

What is your Windows version?

[misol101]

Some trial-and-error showed that (a bit surprisingly), it is the Fn_LoadBmp function that fails when I change user. Everything works up until the call to BitBlt (the innermost call). I have no idea why. It seems to fail only once, then it starts working again apparently.

Anyway, I made a quick and ugly fix, setting iRet to EXIT_SUCCESS no matter what BitBlt returns. Not nice, but if we got that far into the if conditions then something must be right at least (we could load the file etc).

I updated the archive. I can't say anything about if it will fix the sleep issue, since I cannot reproduce that. But please try to reproduce if you have the time, optimally both with the old and new version.

EDIT: The GetLastError from BitBlt is 6, meaning ERROR_INVALID_HANDLE. The handles have just been created though, so umm...

[Compo]

A little more info.
I do not have any more users on this PC, the default guest & administrator are both still in their original disabled position and have never been invoked. (that also means there is no such change user option).
I haven't logged out nor locked the account etc.
I have been in sleep mode several times whilst that window was running with no problem.
I believe it had not been in sleep mode for more than eight hours previous to this time.
This sleep is the only one which had occurred over two different days.
There was no running command etc. from/within that console window, it was sat at the prompt only.

The console window is still working fine as per the image I showed earlier, and the process output I posted.
The image is still in the same place along side the executable as shown is the commandline of the process output I posted.
The console window name is still the same, it took the name of the executable from the command shown in the process output I posted
Nothing is showing in the event logs only informational data and nothing relevant in there either.
Windows version 7 Pro shown in the output I posted.

There was no running anti-malware anti-virus software either.

I will replace with the new version, thanks.

[misol101]

On second thought, maybe it's better to make the "solution" a bit more broad/crude. The polling loop now simply ignores the result from Fn_LoadBmp completely.

Archive was updated again.

[aGerman]

Neither the old version nor the new version failed on my Win10 Home, 32 Bit.
I tried the sleep mode as well as changing the user.

Steffen

[penpen]

@compo:
Are you sure your pc woke up from sleeping, or could it be, that your PC used hibernation instead?
When a pc exits hibernation then applications/functions (BitBlt) may try to access memory pages that aren't currently loaded,
which i suspects is the cause of the above issue.
(This would also explain, why tests with sleep mode couldn't reproduce this issue.)

@misol101
When changing the user, the source/target device context could become kind of unreachable (for each other) because both contexts are getting remapped to a virtualized display (the other user shall not see your desktop, ...).
The two device contexts are located in different processes (cmd and cmdbkg), so it is plausible that they are remapped at different time points.

But you really have to change the user (logout process must have been started) to have a chance to see this issue;
i'm a bit unsure because i don't get it how you mean this exactly:

(I didn't actually change user, just returned back to the one I had)...

Other possible reason of such an issue were listed in Remarks section in the https://msdn.microsoft.com/de-de/library/windows/desktop/dd183370(v=vs.85).aspx, and could be encouraged by high cpu load / a (temporarily) blocked cmd windows (virusscanner, ...), and other "slowing effects".

Default solution (for all reasons): Try again (later), as you actually do.
One could count the fails in row to be sure there is no serious other problem (hung cmd.exe, ...) on which you may (or may not) want to exit cmdbkg.


penpen