I'm trying to debug an application built in Visual Studio C# under MonoDevelop in Linux.
I have the source code, so I followed instructions that appears at Icaza's blog at http://tirania.org/blog/archive/2010/Feb-20.html without success (which basically consists on create an empty solution and set the Execute command to the already compiled application)
The application is executing correctly but when I load the source code file, and set a breakpoint, it never stops.
pdb's were also transformed to mdb's using pdb2mdb command.
What am I missing?
BTW, load source code into Monodevelop and build the application under Linux is not an option right now, due to the big size of the application and lots of tweaks in the build process. Just wanted to debug the compiled assembly.
There is a command line utility for soft debugger, have a look it, this might be what you are looking for.
Related
My question is that how can we debug a .dll script written in C#?
I have created a .dll for an .exe program and I am getting error and I want to debug it but enable to do so. I can easily debug a standalone program but don't know how to debug script for other program.
The program is full screen application (it is a PC game). And I am using SharpDevelop IDE (no plugin installed yet, pure vanilla as downloaded from main site)
And yeah I want to tell you that I am not doing anything like stealing game or something like that which can hurt game developer piracy. Just modding for personal use and it is allowed by developer for single player mode.
Maybe that all information you need. I am sorry for my bad English, this is my first question in stack overflow and I am not very genius, just learning C#.
And thank you.
First of all C# is not a Scripting Language since it's compiled to CIL and not Interpreted during runtime like python does.
In order to debug a .dll or an .exe you need few things in addition to the debugger itself:
A source code file.
A .PDB file matching to the .exe/.dll and the source.
Both things can be manually generated if you don't have them using Reflector or DotPeek and probably other programs.
Debugging for external processes in Visual Studio is possible by:
Attach to process (CTRL+ALT+P in Visual Studio) for a running process.
Start Extrnal Program in the project properties' Debug section.
Setting a specific flag in the registry using corflags or manually.
Using remote debugger if have to.
You can search about every one of them a lot since it is really an infinite topic but I hope you get the basic ideas from the answer, feel free to ask if not.
Have you tried "Attach to process"?
In SharpDevelop I believe the steps are (don't have it installed on this machine):
Run the exe and then al+tab out
Navigate in top menu to Debug > Attach to process...
In the window that appears find the running process of the exe and click Attach
If you are looking to decompile check out this question: How do I decompile a .dll file?
So it's basically as stated in the title. I've created a WPF app in Visual Studio 2013 using some external libraries.
Application works flawlessly on my Development machine (Windows 8.1 x64 + Visual Studio 2013) but doesn't run at all on Production device (Tablet with Windows 8 (NOT 8.1)). App is developed under .NET 4.5, doesn't matter if I try to run Debug or Release version. The proccess just hangs a while and then closes without any errors or messages.
If anyone would know what to do or how to fix this I would be very happy.
Thanks in advance :).
The first thing too look up in this situation, would be the Windows event log. When a .NET application crashes badly, the .NET Runtime will log an event there.
Most of the time, these events will log the stack trace which lead to the crash. This will give you a hint as to what happened.
Such logs are found in the "Application" category, and the source name you need to look for is ".NET Runtime". Usually, there will be another entry with the source name "Application Error", but this one is much less likely to help you.
Another useful technique, is to add a Console.WriteLine call at the start of your program, in order to see if that line gets to run at all.
Depending on what you find using these techniques, you may also want to use tools such as Dependency Walker or ILSpy, as suggested by Mike Dinescu.
Most likely a binding error occurs at start-up but the production machine you're testing on is configured to silently report these errors and it doesn't display the typical dialog box that would inform you that the process crashed.
Don't fret though, that message would probably not help you too much anyway.
What you need to do is inspect the main executable with a tool that can generate a dependency tree and figure out which DLLs are missing. Most likely these will be native binaries, not managed. The usual suspects are the VC runtime, or MFC or ATL libraries but there could be others too. That's why you need to use a tool such as DependencyWalker or RedGate's Reflector to find all dependencies for the main executable.
It is because your external libraries are not compiled into final .exe file. So you either need to include them in the same folder or merge them into exe but this process can be quite tricky. Look for ILMerge. However it is way easier to just copy them with your exe file.
I'm coding an application on C#, and it runs perfectly fine when I click the "Run" button in Visual Studio C# Express 2010. But, when I go to Debug -> Build Solution, after I run the .exe file, it says "XXX.EXE has stopped working..."
I have inserted break-points and commented out chunks of my code, rebuilt the project, and ran again to try to isolate the problem, but I can't figure out what is causing this. The fact that it runs fine in debug mode is strange.
Some things to try:
Check the system Event log for ASP.NET errors.
Try setting the build to Release mode and using Run--no debugging. See if it crashes then. Watch the Output and other windows for any errors during/after the crash. Depending on those results, check that your solution and project properties are correct in both Debug and Release configurations.
You can also build in debug mode, launch it externally, than attach the Visual Studio debugger to the process. But of course if it crashes on startup than that won't work.
You can add Debug.Assert lines to see if you can get one of those to throw.
Wrap your code in a big try/catch and make sure your catch handler somehow reports or logs the full exception for you.
Adding logging would be good idea. You can log to a file or the system event log. I suggest log4net or similar logging tool for that.
I just had this issue and was going to see if I could catch when the error happened via a console window, when I changed my app to console based the program stopped crashing, I commented out all Console writes and set it back into a windows forms app and voila, runs fine now.
-I know its an old post, but its open and unanswered so I think its fair game.
Try adding your application to your Antivirus Whitelist or exclusion list. This is a known problem with McAfee and Avast!
I may be misunderstanding the problem, but if you are trying to run your app from its .exe file (originally located at Visual Studio ####\Projects\ProjectName\bin\x86\Debug\ProjectName.exe), you must make sure that that .exe file is in that original directory. You cannot move it. I ran into a similar problem with XNA projects. If you want to move the.exe file somewhere else, you can create a shortcut to it, but don't ever move it. If you try and run it from a different location, or if you move any of the other files from that directory, you'll get an error message exactly like the one you described.
Also note that some Visual Studio projects (like XNA ones) will not run as standalones. Building the projects doesn't export them into a standalone format, they can only run on computers that have VS and all the projects framework installed, and their .exe file must remain in its original place.
I am developing a DLL using C# .NET 2.0 and Visual Studio 2008 Professional. I would like to debug (i.e. set a breakpoint in) it using Attach to Process and attaching it to the application's executable. I think this is working; at least, I'm not getting any error messages. However, any breakpoints that I try to set get disabled with a little warning message on them stating, "The breakpoint will not currently be hit. No symbols have been loaded for this document." Any thoughts on how I can get debugging with breakpoints working would be much appreciated. Unfortunately, I cannot simply run the application from VS because of the complex nature of its install process; I need to somehow attach the DLL to the installed executable (I can switch the file out, if need be) and debug with breakpoints. Thanks.
Make sure you have a debug version of the code you're trying to attach to. If it's a release version with no pdb files you will get the error you're describing. Also make sure you have have the correct type selected in the "Attach to" selector. The selector should be set to Automatic or Managed.
Enjoy!
If you are sure you have a debug build and the source code matches the build you are attaching to, then check your Debug - Windows - Modules window, and check all the locations for the assemblies you are debugging, their versions, and pdb locations. This will help you narrow down the issue.
I need to compare few function calls and signature between my application and an working application. Here I don't mean any way to reverse engineer or access the source code of the other application , but truly need to know what are the methods , Interfaces used by the working application.
I tried attaching my application to Visual Studio and then , Start>Debug , but this doesn't provide any useful information. Any help.
Reflector Pro Visual Studio plug in can debug not only exe you write, but any other assembly ;)
you can debug code, but once its compiled, its machine language and a debugger in Visual Studio is not going to do anything at all.
In order to get an idea of what a compiled executable is doing, you can use a program like this: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Runtime Flow (developed by me) can show all method calls in the working .NET application without need for source code.
Couple of solutions that I can think of:
Attach the exe with VS IDE Debugger, and use PDB files to debug the exe
Use Reflector to point towards your exe, and check the source. See example.