I need some help in detecting lock screen from a custom credential provider running on Windows 10. I believe Windows doesn't provide any APIs to detect lock screen presence. I'm currently using UI Automation to detect lock screen on Windows 8.1. However, it's not working on Windows 10. Any help would be appreciated.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
The community reviewed whether to reopen this question 5 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
OpenGL and Windows Remote don't play along nicely.
Solutions for this are dependent on the use case and answers are fragmented across the vast depths of the net.
This is a write-up I wish existed when I started researching this, both for coders and non-coders.
Problem:
A RDP session of Windows does not expose the graphics card, at least not directly. For instance you cannot change the desktop resolution and GraphicsCard drivers usually just disable their setting menus. Starting a OpenGL context higher than v1.1 fails because of this. The, especially in support IRCs, often suggested "Don't use WindowsRemote" is unfortunately not an option for many. In many corporate environments Windows Remote is a constantly used tool and an app has to work there as well.
Non-Coder workarounds
You can start the OpenGL program, allowing it to see the graphics card, create an opengl context and then connect via WindowsRemote. This always works, as Windows remote just transfers the window content. This can be accomplished by:
A batch script, that closes the session and starts the program, allowing you to connect to the program already running. (Source)
Using VNC or other to remote into the machine, start the program and then switch to Windows Remote. (Simple VNC programm, also with a portable client)
Coder workarounds
(Only for OpenGL ES)Translate OpenGL to DirectX. DirectX works under Windows Remote flawselly and even has a Software rendering fallback built into DX11 if something fails.
Use the ANGLE Project to do this at run-time. This is what QT officially suggests you do and how Chrome and Firefox implement WebGL. (Source)
Switch to software rendering as a fall back. Some CAD software like 3dsMax does this for instance:
Under SDL2 you can use SDL_CreateSoftwareRenderer (Source)
Under GLFW version 3.3 will release OSMesa (Mesa's off screen rendering), in the mean time you can build the Github version with -DGLFW_USE_OSMESA=TRUE, but I personally still struggle to get that running (Source)
Directly use Mesa's LLVM pipe for a fast OpenGL implementation. (Source)
Misc:
Use OpenGL 1.1: Windows has a built in implementation of OpenGL 1.1 and
earlier. Some game engines have a built in fall back to this and thus
work under Windows Remote.
Apparently there is a middle-ware, that allows for even OpenGL 4 over Windows Remote, but it's part of a bigger package and is a commercial solution. (Source)
Any other solutions or corrections are greatly appreciated.
[10] Nvidia -> https://www.khronos.org/news/permalink/nvidia-provides-opengl-accelerated-remote-desktop-for-geforce-5e88fc2035e342.98417181
According to this article it seems that now RDP handles newer versions of Direct3D and OpenGL on Windows 10 and Windows Server 2016, but by default it is disabled by Group Policy.
I suppose that for performance reasons, using a hardware graphics card is disabled, and RDP uses a software-emulated graphics card driver that provides only some baseline features.
I stumbled upon this problem when trying to run Ultimaker CURA over standard Remote Desktop from a Windows 10 client to a Windows 10 host. Cura shouted "cannot initialize OpenGL 2.0 context". I also noticed that Repetier Host's "preview" window runs terribly slow, and Repetier detects only an OpenGL 1.1 card. Pretty much fits the "only baseline features" description.
By running gpedit.msc then navigating to
Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment
and changing the value of
Use hardware graphics adapters for all Remote Desktop Services sessions
I was able to successfully run Ultimaker CURA via with no issues, and Repetier-Host now displays OpenGL 4.6, and everything finally runs fast as it should.
Note from genpfault:
As usual, this Policy is kept in the HKLM registry group in
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
Set REG_DWORD:bEnumerateHWBeforeSW to 1 to turn ON using GPUs in RDP.
OpenGL works great by RDP with professional Nvidia cards without anything like virtual machines and RemoteFX. For Quadro (Quadro 4000 tested) you need driver 377.xx. For M60 you can use the same driver. If you want to use last driver with M60, you have to change the driver mode to WDDM mode (see c:\Program Files\NVIDIA Corporation\NVSMI\nvidia-smi.1.pdf). It is possible that there are some problems with licensing in this last case.
Some people recommend using "tscon.exe" if you can: https://stackoverflow.com/a/45723167/32453 or using a scheduler to do it on native hardware: https://stackoverflow.com/a/41839102/32453 or creating a group policy:
https://community.esri.com/thread/225251-enabling-gpu-rendering-on-windows-server-2016-windows-10-rdp
maybe copy opengl32.dll (or opengl64.dll) to your executable's dir: https://blender.stackexchange.com/a/73014 and newer version of the dll: https://fdossena.com/?p=mesa/index.frag
Remote Desktop and OpenGL does not play very well. When you connect to a Windows box the OpenGL Driver is unloaded and you end up with software emulation of OpenGL.
When you disconnect from the Windows box the OpenGL driver is not reloaded. This causes issues when you are running tests on the machine as you have to physically login to the machine to reset the drivers.
The solution I ended up using was to:
Disable Remote Desktop.
Delete all other software for remote desktop access. Because if it's used for logging in remotely the current set of drivers loaded may be messed up.
Install NoMachine
NoMachine is my personal favourite (when it does not play up) for a number of reasons:
Hardware acceleration of compression (video of desktop).
Works on Windows and Linux.
Works well on low-bandwidth connections especially if the client and server have the necessary hardware for compression of the data stream.
On Linux you get your desktop as you last left it when you were sitting in front of the machine.
On Windows it does not affect OpenGL.
currently free for personal and commercial use. Do check the licence in case it's changed.
When NoMachine plays up it hogs the CPU but this happens rarely. It is however in active development
Others to consider:
TurboVNC
TightVNC
TeamViewer - only free for personal use.
I have a game that I need to figure out a specific issue.
When you maximize, move or resize the window the DirectX device resets. But before it resets all graphically allocated objects should be released that are not part of the managed pool.
As for this game there seems to be 30 unreleased objects when the application quits (from basic directx debug library output) which leads me to assume that when the device is reset, the same issue occurs. This causes the game to crash when you maximize, move or resize the window which is obviously not acceptable.
More research has resulted in that you can enable excessive debugging in DirectX via DirectX Control Panel, except if you have Windows 8 no such thing is available. You can install the DirectX sdk and open the DirectX Control Panel, but all the features on Direct3D tab is grayed out. This excessive debug output level would then print out the addresses of allocations that have not been released upon exit, which could give me a clue of what is actually not released during a reset device event.
The game is built in C++ using DirectX 9 libraries with Visual Studio 2010.
Ps. Windows 8 comes with DirectX SDK by default but no control panel options, you must manually install the DirectX SDK to get it.
My question is, how can I enable excessive directx debugging on my environment (Windows 8 Pro)?
Are there any way you could potentially enable excessive debugging per application in the source while its compiled with directx debug libraries, or must you use the DirectX Control Panel for that?
Cheers, Nicco.
You can enable some debugging through the registry as mentioned here
Also, I played around with the control panel and noticed it modifies the following keys on my (windows7) machine:
HKEY_CURRENT_USER\Software\Microsoft\Direct3D\ControlPanel
Checking "Use Debug Version of Direct3D9" in the control panel set the "LoadDebugRuntime" registry key to a value of 1 (otherwise it was 0).
Checking "Break On Memory Leak" set the "BreakOnMemLeak" key to 1.
Checking "Break On D3D Error" set the "BreakOnDPF" key to 1.
Note that these same keys were also duplicated at:
HKEY_CURRENT_USER\Software\Microsoft\Direct3D\
So if you don't have the control panel installed they might work there as well.
I would like to programatically control the volume of a particular application in WinXP.
I came to know abt one API waveOutSetVolume(), but it controls the application volume in Win Vista & Above, for XP it just affect the entire system volume.
Please advise how can we achieve this in XP?
Moreover how to Uncheck/Check the SYstem volume Mute check box as well.
As you said, application-level audio levels are available from Vista OS, so XP has no ability to control it.
More info here: http://msdn.microsoft.com/en-us/library/bb945061.aspx
Your second question related to mute, you simply call waveOutSetVolume:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd743874%28v=vs.85%29.aspx
Our Direct3D9 app works perfectly if we fully start Windows, and then launch it.
However, if we tweak Windows' startup process so that Explorer is not ran, and just Windows and our application are started, our app slows down horribly. CPU consumption goes to 50%, even when idle (normally, it's near 0).
This can be fixed by starting the Task Manager, starting Explorer and restarting our app. But that's not acceptable; our app must run without Explorer.
Could this be a Direct3D thing? Our app is full screen, Windows version is XP SP3 with all latest updates, and Direct3D version is 9.0.c. If this is not Direct3D related, how could I go about debugging this?
Solved it. Went to Control Panel->UserAccounts->Change the way users log on or off and saw that "Use the Welcome screen" was checked.
Unchecking that solved it. It seems that when the Welcome screen is active, since it uses a different resolution than the desktop's, conflicts ensue. And I didn't check, but it seems that this caused hardware acceleration to be temporarily unavailable and thus software rendering was selected, killing the CPU.
I'm working on a small C++ project which involves a launcher application that does a bit of setup work and then invokes the real application. To be precise, I'm working on the launcher application - the real application is done by a separate team. These programs are both deployed to Windows Mobile devices. Now, I'd like to be able to get notified of all keyboard and mouse activity in the real application (which my launcher starts) - and I cannot modify the real application to do this.
On Windows desktop machines I'd do this using the SetWindowsHookEx API. However, this is unavailable on Windows Mobile.
I also considered subclassing all windows in the process so that I can handle the relevant window messages for keyboard and mouse input - but I don't know how to get notified of new windows which the real process creates.
Does anybody have some thoughts on how to achieve this?
You can use SetWindowsHookEx, it is only undocumented. This is a good post about hooks and subclassing on Windows Mobile.