I recently converted a mingw/cygwin build to a Visual C++ cl.exe build and upon initial testing found it crashes at launch. I then installed it in my developer environment to debug it, under which it runs just fine. My initial suspicion was that I was linking to a different DLL in that context, but examining both processes in both contexts with Process Explorer showed that they were using the same versions of the same DLLs.
Since I can't reproduce the issue with Visual C++ installed I installed the remote debugger on the client machine, but I can't manage to attach to the process quickly enough before it crashes. Is there a good way to go about doing this? This would be easy if I could launch the process under the debugger locally, but that doesn't look like a viable option here.
Any help would be greatly appreciated. Thanks for your time!
You should be letting the remote debugger start the debugee process on the remote machine.
Related
I'm putting this out here to save someone else some of my pain. Today I built my Blazor solution and it simply hung. Searching on this will give you alot of results that have nothing to do with Blazor.
There was no indication as to what happened and I didn't find out until I tried updating VS that a Node.exe process running on my machine.
Node.exe is the NodeJS process that is used by VS as a debugger proxy for the client-side WASM project. Kill the Node.exe process and you should be able to build again.
I've tried using the standard Blazor template app to remote debug on an Azure app service and I get the following error:(the app run fine if a compile to release, though not debugging of course.)
I compile to debug any CPU.
UPDATE
I can debugger in my .razor pages.
PRIVIOUS
Judging from your error message, the problem may be caused by unsuccessful release of some files and other factors when the program was released.
In order to solve your problem, you can tell us the version of Visual Studio you are using and how you created the project. This problem is mostly related to your development tool environment configuration.
Here is a suggestion, test it by yourself and it runs normally.
Visual Studio 2019 Enterprise Edition (other versions should also be normal)
Configuration before project release
Start remote debugging
The final result
I'm investigating using NTVS (https://nodejstools.codeplex.com/) with Visual Studio 2013 to debug my Meteor/Node application. I can't figure out how to get debugging to work.
The problem is that when Meteor starts it copies all of my sources to the .local directory and runs them in a new instance of Node.exe. This confuses NTVS because it can't follow on into the child process. And I can't set breakpoints because Visual Studio doesn't know how to deal with the fact that the files I am editing being different than the ones that are running in the .local directory.
What I'd like is some way to run my Meteor based code under Node.exe straight from my sources, without the pre-bundling steps. Is this possible?
I'm fine with not having development niceties like hot-code pushing and package updates on-the-fly. I can manage that in other ways.
'meteor bundle' doesn't do the trick because (a) it takes too long and (b) it still makes the copy that throws off breakpoints.
Hopefully there is a way to use Meteor as an awesome library separate from Meteor as a runtime environment so I can debug it with NTVS.
Thanks,
/Michael Ost
if the functionality of the meteor tools for Visual Studio are not sufficient, why not contribute to the project.
It's a bit old (last commit 18 months ago) and hence probably outdated, but it will give you a head start as to how to make things work.
You can run your app in debug mode using meteor debug and then attach debugger to port number 5858, It should work for all type of node.js debuggers e.g. Visual Studio, Visual code, Webstorm etc because they all have "attach" debugger option next to "debug" option.
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.
I have an .exe that crashes in release mode. I want to debug where the crash occurs.
How can I use VC++ to debug a crash in a release-mode .exe?
You can run Visual Studio and attach it to a process to debug.
Also check through the Windows Event Viewer (an often overlooked source of information) for any exceptions that Windows may have caught.
Firstly if you have access to the code you can open the workspace in visual studion and debug it by pressing F5 button.
Secondly go through the steps that leads to the crash. At that point of time check the location pointed to by the call stack.
This will give you indication on the funciton or line where crash is occuring.
We are assuming this application was written in VC++. How often are you able to reproduce this issue. Is it like everytime you can reproduce it or how is it.