I am running Windows Server 2012 R2 and I am running the program FireDeamon to run my game services, but upon clicking the pop-up message it'll just either bring me to a blue or black screen. I already tried setting the value in the registry to: HKLM\SYSTEM\CurrentControlSet\Control\Windows\NoInteractiveServices=0 and rebooting the machine but this did not work, I even tried it twice.
So is there an clear and working solution for this issue? If not, could someone please provide me with a good working alternative for FireDeamon.
Related
Pretty much title.
Cursor constantly changes from standby to loading, but other then that the screen stays white.
I have tested it on windows server 2019 and it worked, same goes for my local computer which is windows 10.
I tried building a x32 bit version and it crashed.
There is barely any information on the internet regarding older versions, and the one thread I saw mentioned what Ive tried already.
Can anybody point me to the right direction? I'm kinda clueless right now and trying to compare things like .NET Framework and such (although I'm pretty sure it's not related at all?)
Thanks!
EDIT:
I'm getting an error in the event viewer that theres a faulting modoule, and it is ntdll.dll
going to continue research for now!
Just incase anyone sees this and have a similar issue:
1.The desktop on our citrix server was programmed to be located on a network share and not on a physical hard drive, so I had to move it to the proper folder.
2.The application worked only when I placed it on the local drive, and only as a 32 bit application.
I spent two days basically trying everything on a 64 bit application, because when I tested the 32bit one it just crashed, but it turns out they were two seperate issues which are finnaly resolved!
We are currently in the process of migrating from Azure RemoteApp to another RemoteApp deployment as the current version goes end of life soon. An issue has been raised in UAT whereby Windows cannot be dragged across the screen for more than a split second (only seems to occur in instances where the Window in question is primed to be merged with another Window).
Here are two such examples:
https://drive.google.com/open?id=0B1S4OHN3Sdfyck13UVFzT0c1eWM
https://drive.google.com/open?id=0B1S4OHN3SdfyOHg4WlJmVGdIQTQ
This problem seems to only occur when connecting to Remote Apps via Windows 7 (which is what our users use). When tested in Windows 10 and OSX there was no problem. We also tested this inside a Remote Desktop and it was working.
Our current live deployment doesn't have this issue (connecting to Windows Server 2012). The deployment with the problem is using Windows Server 2016 so we spun up a host server using Server 2012 and still had the same problem.
We have also tried modifiying settings in the connection file to eleviate the problem. These are some of the settings that didn't seem to help the problem when we changed them:
bitmapcachepersistenable
disable full window drag
disable menu anims
disable themes
enablesuperpan
Has anyone come across with problem or know how to fix it? I'm happy to answer any questions about our setup.
Recently, we have switched our server that handles Remote Desktop connections from 2003 to 2012. When I run the same winForms program on each server, the one on 2012 appears to be larger. My workstation is Windows 10 and I put the resolution down to 1280 x 768 so I can see the screen at the top and the bottom on each RDP session on each server. On the 2003 server, the screen fits the desktop. On the 2012 server, the screen goes below the desktop and you can't see the bottom. It appears the controls such as the text boxes are just a little larger which is forcing the whole program to be larger.
I did check the "Change the size of text, apps, and other items" on Windows 10 desktop and it's set to 100% (Recommended). This doesn't seem to be the problem.
Does anyone have any ideas why the behavior would change between the two servers?
This is probably because 2012 does DPI-scaling (so the remote session tries to adjust the DPI to the same as it is on the client session): https://superuser.com/questions/830234/remote-desktop-into-windows-8-1-pc-with-high-dpi-scaling (also, I guess that you mean 2012R2 because DPI scaling only appears in RDP 8.1 which corresponds to 2012R2).
I have the same issue and I'm just blown away at the amount of money my organization has spent on RDS 2012 and it's been nothing but a complete nightmare. We have various types of Surfaces, desktops and monitors all of which require each user to have the ability to change the resolution and display settings on the actual terminal services end. We've tried everything on both the client and server side to correct this but displays are either too large for some users and too small for other users. Why doesn't Microsoft come out with a patch like there was for server 2008???? I understand the DPI scaling technology, and I will tell you it's horrible when you have multiple versions of the Microsoft Surface and other brand desktops (and yes we have installed the desktop experience on the server end).
Here's what I strongly recommend:
Abandon the whole terminal server 2012 configuration and go with individual virtual desktops. After this, install the display and resolution patch for each desktop which lets each user configure their own resolution and display settings. Not only will your users thank you but you'll thank yourself!!
We had this issue for about a week and I restarted our Windows Server 2012 on remote desktop and DPI is back to normal! :) I guess this must be some automatic Windows update that fixed this.
I'm trying to debug a simple "Hello World" Windows 8 application on Surface RT but can't figure out how to connect it to Visual Studio 2012? I have Windows 8 installed on my VMWare machine and the following instruction but no result, the Surface is not visible for in Visual Studio. Is there any direct way to connect Surface to the PC by some type of cable?
Check if your network is in the same domain.
next try opening the debugger in the surface and select options
in options you will find allow any computer to connect
under authentication
enable the option. Although it will warn you that it is not safe but will work.
authentication mode doesnot make a big difference if you are xonnecting locally . I dont have the links currently and answering from tab.
if these points do not work leave a comment. Ill look into the matter tomorrow when ill be on my system till them try. :)
First off, I think I've been to every website and forum there is that's discussing this issue and I've tried many different things. I'm at my wits end. This is the dumbest thing and I just want to start coding again!
I'm using Visual Studio Express 2012 for Windows Desktop. I have a x64 project I'm trying to run in Debug mode using the local windows debugger. The only external library I'm using is that of which is required to run DX11.
I attempt to run my program and it freezes. A window pops up saying "A remote operation is taking longer than expected."
I click Terminate and another window pops up asking if I'd like to terminate the remote session. Why yes, I would.
Then it says, "Unable to start program (my path leading to my .exe). The network connection to the Visual Studio Remote Debugger has been closed."
To my understanding, because Visual Studio itself is a 32 bit application, it needs to use the Remote Debugger to compile to x64. Is that correct?
Regardless, I'm still failing to see where that would break down. I've ran several repairs on VS and upgraded to Service Pack 2 (or 1, whichever is the latest).
I've ran a windows repair and uninstalled any VMWare type stuff on my computer. I'm not using a VPN.
I've even copied msvsmon.exe from my laptop (working instance of the project) over to this computer and still no luck.
I'm about ready to Nuke my OS and do a clean install on everything. sigh
Found the problem. It wasn't Windows Firewall like other threads describe. It was my internet filter. I guess it decided to try and block msvsmon.exe because it was using the network. Adding it, along with WDExpress.exe to the application exceptions list did the trick.