I'm having some problems (as some of you will see from another question I asked) with getting a program I made in Visual Studio 2010 to run on another computer.
My computer is Windows 7 x64
The destination computer is Windows XP x86 (SP2)
I've already checked to see that I'm compiling for x86.
Anyway, my question is: Is there a debugger I can install that will tell me what errors the program is having? Like a .NET Debugger that does not involve me installing Visual Studio 2010 on the destination computer?
If you have access to the client computer when it is running the program, the easiest thing would probably be to deploy the remote debugger, and debug the program on your own machine, while it is running on the client PC.
Otherwise, you can use DbgClr, which is distrubted with the .NET framework SDK.
One option is to use WinDbg + the SOS extension. This is a much lighter weight debugger that is easily installable but has a steeper learning curve than Visual Studio. I often use it though when I need a light weight debugging experience
WinDbg http://www.microsoft.com/whdc/devtools/debugging/installx86.Mspx
SOS: http://msdn.microsoft.com/en-us/library/bb190764.aspx
Another option is to use a program like ProcDump to take several snapshot dumps of your program on the remote computer and USB copy them to debug back at your workstation.
http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
You can save a dump at various triggers like an Unhandled exception. Visual Studio can open the dump back at your workstation and 2010 supports mixed mode debugging.
Related
The situation is as follows:
I have a Windows 10 Machine with Visual Studio 2019, and created a c# .NET project in debug mode there and it Works.
The program happens to throw an unhandled exception with a meaningless/ambiguous message on a different Windows 7 machine. On that machine, Visual Studio 2008 happens to be installed. I get asked whether to use it for debugging, and I'd love to do so, to get the code which caused the exception. After copying over all the source files onto the Windows 7 machine I find that I cannot load the project using Visual Studio 2008, since VS 2008 refuses to load project files created with newer versions of Visual Studio.
I do, however, get an offer to use the Visual Studio 2008 debugger upon the crash, but if I use it, all I get is rather useless assembler code and a meaningless crash location address, since the debugger is not connected to the source code, and Visual Studio is not, AFAIK, capable to link that address to the source code. So the situation is, that I have all the source and symbol files available on the target machine, but the debugger does not load them, I don't know whether I can somehow show them to the debugger outside Visual Studio, and starting the project from Visual Studio 2008 is not possible because it won't load the project source files.
Is there any way I get a meaningful debugging, I mean with all the files in place it should be possible to debug with source display, even if the Visual Studio versions don't match.
Framework version is 4.x (most recent, think is 4.7). The message says that a service hasn't been started or is missing on the W7 machine, unfortunately no hint which of the 1000 possible services is meant. If I load the VS 2008 debugger, I get the fairly useless hint that the crash happened at address $..... (very, very long hex address). If I knew which part of the program caused the exception I could find out with ease. The question isn't targetet to to resolve the exception, but solely how to use the debugger to find out where the exception comes from, under the described circumstances.
You can use tools like dnSpy and my Runtime Flow for light weight debugging to find which part of the program caused the exception.
Is there any way I get a meaningful debugging, I mean with all the
files in place it should be possible to debug with source display,
even if the Visual Studio versions don't match.
I think you could use Remote Debugger just as Pavel said. It will use the local VS2019 to debug the source files on the remote computer without VS2008.
First, you should install the remote tool or just copy the Remote Debugger folder into the remote computer and then config as this document said, run it as Administrator on the remote computer.
Then, use IIS to run your asp net source files(you have the whole project source files and output files) on the remote computer
And on your local computer, open VS2019, use Attach to Process to catch the process of your project from the remote machine.
More info you can see this official document about it.
Besides, you can also use Debugging Tools for Windows-----WinDbg.
I have a legacy solution in C#, .net 1.1 and Visual Studio .NET. My solution consists on many projects. Once I run in debug mode my initial project, then I attach to other processes. When I try to attach to a process, Visual Studio IDE crashes and I need to start IDE again. It's a pain!
Anyone has some idea on how to get rid of this?
I'm not sure if there's a fix, but a way around it is to limit the number of processes you're attaching to.
Start with just connecting to one, then increase the number if stable.
To identify which project is running on each port you can run
IIS6
c:\windows\system32\cscript c:\windows\system32\iisapp.vbs
IIS 7
C:\windows\system32\inetsrv\appcmd list wp
Yesterday, I encountered the problem multiple times that Microsoft Visual Studio 2013 restart unpredictably when it loads very large C++ and C# solutions.
I researched Stack Overflow and found this particular article: Visual Studio 2013 hangs when opening a solution
which suggests deleting the suo files. However, when I tried that the problem persisted.
I also tried uninstalling and reinstalling Microsoft Visual Studio 2013 and still the problem persisted.
I then tried loading a smaller solution consisting of a C# solution and a C++ project and that succeeded in loading, compiling and linking.
I was wondering why I suddenly encountered this problem. Could the cause of the problem be related to the amount of 64 bit physical memory I have installed on my 64-bit desktop system? Alternatively, could it be due to a computer virus even though my desktop system has an antivirus package installed. We are tring to avoid reimaging the disk of my 64-bit desktop system and reinstalling all the software which could take 2 days to complete. Any help is greatly appreciated.
It's probably some plug-in misbehaving. You can try disabling them (Tools => Extensions and Updates) and experimentally determine which one is causing the issue.
If you want to go all-in, you can debug it:
Download and install WinDbg 32-bit
Run Visual Studio under windbg: windbg -g "%VS120COMNTOOLS%..\ide\devenv.exe" c:\my\solution.sln
Watch the incredible amount of debug info VS spews into
WinDbg
If Windbg breaks, inspect the stack - maybe some DLLs on it will clue you into which plug-in is the culprit.
Open file explore and past this command
'%AppData%..\Local\Microsoft\VisualStudio\12.0\ComponentModelCache'
Then remove 'ComponentModelCache' folder.
Restart the visual studio.
Can anybody explain why i'm suddenly getting this when trying to do any kind of performance profiling (the same way i always have) from within VS2012.
VSP2340: Environment variables were not properly set during profiling run and managed symbols may not resolve. Please use vsperfclrenv before profiling.
I've googled and tried a few things, but i'm unable to find out how to get this working from within VS2012 again.
I found somebody with the same unanswered issue a couple of weeks back here: VS2013: "VSP2340: Environment variables were not properly set" even when running from IDE
Thanks in advance.
I've had the same issue on Visual Studio 2012. Follow the steps below:
Start - All Programs - Microsoft Visual Studio 2012 - Visual Studio Tools
Right click "Open VS2012 x64 Native Tools Command Prompt" and select run as administrator
The command prompt opens. Run vsperfclrenv /globalsampleon
Reboot machine
I just migrated to Windows Ultimate 64 SP1, because my system's hard drive crashed. I installed Visual Studio 2005 SP1 and all the patches that Microsoft has recommended. I finally got my source code from my SCM, but now debugging does not stop on any of my breakpoints I have set. This is just a plain Winforms app, nothing fancy.
The first thing I did was to change the build target to x86. No dice. Then I went and downloaded Debugging Tools for x64, still no dice. I set the debugger to break on all exceptions both handled and unhandled. No dice either.
I've been looking at Google search results, but no luck there either. I've been at this for 3 days now with no luck. Has anybody dealt with this issue before?
Update:
The projects are all set to Debug (x86).
Breakpoints stay normal when the debugging session starts.
I already did a re-install, and that didn't work either.
I am running as Administrator and turned off UAC.
I attached to the project using "Attach to Process", and I was able to step into the code that way. I'm hoping to find out why it is not auto attaching, in order to avoid having to do this manually every time.
This is listed as a known issue for VS2005 on Vista (Via MSDN):
Title: Just-In-Time (JIT) Debugging of
an elevated process will fail
Description: Elevated processes cannot
be JIT Debugged by VS 2005. This
includes system processes, such as
IIS, and applications started by
selecting ‘Run as administrator’.
Workaround: The debugger must be
attached manually before the debugger
will catch unhandled exceptions or
user break points
(System.Diagnostics.Debugger.Break,
__debugbreak, etc).
Couple of questions.
When your code fires up, does the breakpoint become an empty circle with a tooltip that indicates that the breakpoint won't be hit? Or does it become a full circle with a tooltip that indicates the process it's attached to?
You can try manually attaching the debugger to see if you get any traction that way. Just fire up the app and once it's running, go to the debug menu and choose "Attach to Process" - select the process that your app is running in and click "Attach".
I run Vista64 w/o issues - VS2008, though.
I am using Visual Studio 2005 with the same patch level on both Windows Server 2008 x64 and Vista x64 SP1 without any issues.
Are you running it as admin? When all else fails, try uninstalling and reinstalling.
Insure that the project is set for a debug compile and not a release compile, as the release compile doesn't contain your debug information.