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.
Related
I'm attempting to play Mabinogi by Nexon on Linux Mint 20 (Ulyana) using Lutris. I've previously used Lutris to play Heroes of the Storm but otherwise don't have much experience with it (or with gaming on Linux, in general). There's no installer on the Lutris website for Mabinogi like there was for Heroes of the Storm, so I was on my own to try and figure everything out.
What I've tried
I started by downloading the Nexon Launcher Installer from their website. I configured Lutris to launch this executable using Wine within a simulated Windows environment. When it first launched I noticed several files were created ("drive_c", "Program Files", "Users", etc -- mimicking a Windows file system). The launcher installer ran without issue and I installed the launcher to "C:\Program Files (x86)\Nexon"
I then re-configured Lutris to try and launch the Nexon Launcher instead of the Nexon Launcher Installer. When I hit "Play" in Lutris, nothing happened. Running ps -ax | grep "Nexon" showed that it was theoretically running, but there was no window or visible UI even after several minutes of waiting. I checked the Lutris logs and noticed a message about a file missing (something like "10000.manifest.hash"). I Google'd this error and found plenty of people in Windows who had trouble running the Nexon Launcher with the same error, and the solution was to just install Mabinogi through Steam.
So next I downloaded the "Wine Steam" runner in Lutris and set this as the runner for Mabinogi, plugging in the app ID (212200). After Steam installed, launched, logged in, and downloaded Mabinogi I tried to launch the game. This time I saw a window pop up saying "Mabinogi is launching" and in the bottom-right the Nexon Game Security icon popped up, but then everything closed and the game never started.
Finally out of desperation I tried setting up a virtual computer using VirtualBox to play the game in its native Windows environment. I installed Windows 7 (the minimum required version according to the Nexon website). I downloaded Mabinogi through Steam on the virtual box. Upon trying to launch Mabinogi, I received the error error: "api-ms-win-crt-runtime-l1-1-0.dll is missing". I'm curious if this error is related to why I couldn't get Mabinogi working in Lutris.
Looking at a game that I had previously played in Lutris (Heroes of the Storm), I noticed a very similar DLL was listed in the "DLL overrides" section: "api-ms-win-crt-private-l1-1-0.dll". So I tried adding the runtime DLL to the overrides in Mabinogi with the same value ("n,b") - but this didn't work.
Looking at the Lutris logs when I try to launch Mabinogi through Wine Steam, there are several errors from \main\game-launch.js:109. I'm not sure if this JS script is part of Lutris of part of the Nexon Launcher, but it could provide some hints. Among the logs the following lines stand out as potentially meaningful:
...
ERROR: ld.so: object '/usr/$LIB/libgamemodeauto.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
...
fixme:d3d12_get_vk_physical_device: Could not find Vulkan physical device for DXGI adapter.
fixme:d3d12_device_caps_init_feature_options1: TotalLaneCount = 2560, may be inaccurate.
...
warn: OpenVR: Failed to locate module
...
What I don't know
I'm not familiar with using Wine and I've never written a Lutris installer. Up until now I've only ever run Linux binaries on Linux and Windows binaries on Windows. So there's a lot I don't understand, like: What's Vulkan? What's DXVK? How do "override DLLs" work? Do I need to provide alternative DLLs for anything I want to override? What does the value "n,b" mean in the DLL override?
I'm welcome to any help
After a lot of work and research, I've gotten as far as I can and figured out where the major road block lies. The simple answer is: You cannot run Mabinogi in Lutris
Mabinogi uses an anti-cheat system that runs in kernel mode (ring 0). Wine runs in user mode (ring 3) and therefore cannot run this anti-cheat program.
The only solution is to play Mabinogi within a virtual machine (e.g. VirtualBox), since VMs run on a hypervisor (which from my understanding is kind of like a "negative" ring number, but effectively ring 0)
If you want to try some other Nexon games, I got the Nexon Launcher working in Lutris / Wine fairly easily. The trick was to download the latest Nexon Launcher since the older one (linked on the Mabinogi website) isn't sending a valid request to download the manifest file so it gets a 403. The latest launcher can be downloaded here: https://games.nexon.net/nexonlauncher
So I built a huge website for my company using the AnyCpu option. I didn't think it would matter - I have a 64bit machine with x64 windows, it's getting deployed to a x64 server, and there's no attached dll's, so it should just all be in 64, right?
Well, in the process of trying to implement some security, the company's support told us the application MUST be strictly x64. I figured it was, but to humor them, I went into the configuration manager, and changed all the target cpu, platform etc settings to x64.
Unfortunately now, it breaks when I hit f5 to run it. I've run into this before, I think, and I vaguely remember needing to delete some temp internet files somewhere, but I tried closing VS, deleting the bin folder, deleting the root folder from /framework/tempASPfiles... but I still get the BadImageFormatException - "an attempt was made to load the program with an incorrect format."
What's the best and fastest way to convert an app to x64? and am I right in thinking I need to delete some files somewhere?
I have a Kernel mode filter driver project. Host: Win8 Pro x64 running VS2012, Target:Win8 Pro x64 VM on the same machine. I was able to provision the VM through VS 2012 over the network. I deployed the package project. When I try to deploy and Install the package from VS, I am not able to succeed. So I manually installed the driver and the driver works fine. After installing the driver manually, I attach to the kernel of the VM and click on Break all. I find the Kd console in the immediate window of VS '12. I type the command "bu !DriverEntry" and then I type the "g" command. I see the message Debuggee is running. When I place break points on my code and press any key in the VM, I don't see the break points getting hit in my code. Need help!!
Use Fltmc command to load and attach your filter to a specific drive
You can put breakpoints directly in VS without the need to type in the console, if your filter is getting loaded after you type fltmc load "filter name" VS should stop at the driver entry function breakpoint, you may also need to attach it.
Dont forget to check if your debugger is working by when you click break all target machine should freeze.
I wasn't able to debug through VS. I went for a work around and this time I used a Win7 VM. Made use of the KdPrint() method and used the DebugView tool to see the messages. This is a lengthy process but atleast I'm able to debug my driver. Hope this helps someone else too
Windows 7, VS2012-Update1, x64.
If i start e new MVC-project, and add the Azure project to it. I can't debug it locally in the azure emulator.
The error:
Operation taking longer than expected
A 64-bit debugging operation is
taking longer than expected. This may be caused by incompatibilities
with 3rd party networking softwar. See help for troubleshooting these issues.
When i Terminate that message (twice):
Windows Azure Tools for Microsoft Visual Studio
There was en error attaching the debugger t the role intances
'deployment18(18).mvctest.Azure.Website_IN_0' with prces Id:'8752'.
Unable to attach. The Microsoft Visual Studio remote debugging monitor
has been closed on the remote machine.
The first message, I already found that if you change your website target to x86 that this can solve the problem. (this solved a problem for debugging unit-tests)
But if I change it to x86, the nex message pops up:
Windows Azure Tools for Microsoft Visual Studio
Cannot start debugging. The role was built for a platform incompatible with the windows azure compute emulator. On this system the compute emulator supports anyCPU and x64.
If i start without debugging (not x86), the windows emulator starts, and the website opens.
Is there a solution to solve this that we can debug x64 websites on the azure emulator?
Thanks.
Problem solved:
The issue was, that oour normal account didnt had admin privileges, and that we had to use an other admin user his credentials to run it in admin mode.
If i logged on with that admin user and started everything, that user couldn't also load the azure emulator.
Every co-developer had the same issue.
But when the normal account had back the admin privileges, the emulator started normally.
So i assume that there was something missing for those admin account (what i don't know)
Ensure that the remote debugging service and the machine debug manager (for x64) are properly installed and running (services in Automatic, especially not disabled).
You can also try to download and reinstall the remote debugging tools following instructions here
Even if it is on the same machine, chances are that debugging for the emulator goes through the remote debugging path
Been googleing this for a while now and it looks like the problem is connected to network drivers installed on windows. Do you have a VPN installed? Uninstall it and try again.
Otherwise it could be some of the network card drivers. Same here, uninstall and try again.
Some people have solved this by upgrading visual studio.
I followed the instructions in this link: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx to install the remote debugger (2012) on my server where the application is running in hope to debug it remotely from my dev machine running visual studio 2012.
I cannot even get as far as viewing the list of processes to attach to on the remote machine. I keep getting "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named [name]. Invalid access to memory location".
I have managed to successfully connect a few times but then the attach fails immediately then I cannot connect again.
This is causing huge issues for me as I cannot remote debug anything. I must be missing something glaring. Please someone give me a solution.
I've found the only way to correct this is by restarting Visual Studio.
Worked for me. I found it at this blog post about invalid access and remote debugging.
It turns out the one thing I missed was to tell Visual Studio where to find the .pdb symbols relating to the remote process. To do this go to Tools -> Options -> Debugging then in the Symbol (.pdb) locations add the remote location to the pdb files.
To clarify, I was attaching fine but could not break into code. Now I can. Be aware though that there are other hurdles before you get to my stage where I was attaching to the process successfully but could not catch a breakpoint.
I recently had someone else report this and debugged the issue on their machine. The "Invalid access to memory location" errors are due to an issue in Windows, it can be addressed with this hotfix.
I have had this problem in VS 2012, 2013, 2015 and 2017. Based on other answers it is likely that the problem is related to running a 32 bit version of Visual Studio on a 64 bit PC. Sometimes, as others have recommended, restarting Visual Studio fixes the problem but the best solution I've found so far is to start Visual Studio without a solution, open Debug -> Attach to Process, change the Connection Target to the remove server and wait for the process list to load. Then Cancel, do not attach yet. Load your desired solution and then come back to Attach to Process and the remote process list will still be loaded. Connect to your desired process and everything should work properly from then on.