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.
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 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.
I have been stump in this problem for a few hours now. I hope someone has had a similar problem to this.
We have developed a prototype .Net(C#) dll using VS2010, and would like to be able to call this dll in a both C# applications and VB6 application.
My question is:
Is it possible to debug a VB6 application that is calling a .Net dll? I get an error message "Automation Error The system cannot find the file specified"
The error message suggests that there is something missing for my VB6 app to find the .Net dll.
I am aware that if the VB6 application has been compiled, and the .exe has been created, the VB6 will successfully call the .Net dll functionality when using the .exe
However it is important that we can debug through our VB6 application. Unfortunately debugging does not allow you to step over the line of code instantiating the .Net DLL's class object. I can't seem to do this.
NOTE: I have looked around forums and MSDN documentation and I mostly find solution for calling a VB6 dll in .NET; which is unfortunately the opposite of what we need to do.
NOTE: I have already registered the compiled .Net(C#) assembly, and referenced it in the VB6 project.
I have however found these two pages, which seemed to be what we need, but its a solution for calling a .NET(c#) dll generated using VS2005. This doesnt seem to work when the .NET(C#) dll was generated using VS2010.
site1
site2
If someone could give any suggestions or direct me somewhere I can get one, that would be great.
Thanks
SOLUTION
Thanks to #HansPassant, I have found the solution.
To debug a VB6 project that contains a C# .NET assembly, you need to register the .NET dll through both "regasm" and "gacutil", then make sure to close and reopen the VB6 application before you start debugging.
This is not a problem, VB6 uses its own debugger that doesn't get in the way of any other debugger, including the managed one for C# code.
You start from your C# class library project, ensure it is selected as the start project. Project + Properties, Debug tab. Select the "Start external program" option and enter the path to the VB6 IDE. Typically c:\program files\microsoft visual studio\vb98\vb6.exe. Set a breakpoint on the method you want to debug.
Press F5 and the VB6 ide will start running. Load or create your vb6 project. Note how you can add the path to the .vbp project in the previous step so it will automatically load your project.
Start debugging your vb6 project as usual. As soon as it starts using your [ComVisible] C# class then your C# assembly gets loaded. And the breakpoint will hit when your vb6 code calls the method. Switch back and forth as needed. Note that you cannot single-step from vb6 to C# code, you have to set breakpoints to get the debugger to stop.
Ah, the wonders of using .NET from VB6 in a debuggable manner.
in the VB6 project compile options (reached using the Options button on the Make Project dialog window), choose the Compile to Native Code, No Optimization, and Create Symbolic Debug Info options. Then compile your VB6 project. These options allow proper VB6 binary-to-source mapping.
Go to the Configuration Properties...Debugging property page of your solution and change the Start Action to launch your VB6 executable.
In VS Solution Explorer, go to File...Add Existing Item and navigate to the folder containing the VB6 source code you want to debug. Double-click on the VB6 source code file you want to debug, and a source window should open in VS that allows you to set breakpoints in the VB6 source code.
Make sure that your .NET library has a public default constructor. This is essential.
Now also set any C# breakpoints that you need. Do not step into the .NET code - this doesn't work.
When you start debugging with VS, your VB6 and C# breakpoints should be hit normally.
One approach is to debug each individually:
Debugging the VB6 code can be done in the IDE after compiling the C# DLL and adding it as a reference to the VB6 project.
Debugging the DLL with the VB6 host is possible in Visual Studio by compiling the VB6 project and using it in the project properties as the executable to run.
In some cases this is simpler/quicker than setting up the environment to debug both simultaneously.
This approach will require having at least the framework of each working beforehand.
I have an application I made that I lost the source code for, but the application has worked on my Win 2K computer. Now when moving to a Windows 7 computer it won't start. Probably some dependencies that needs to be solved, but I don't know which. The only error I got is a System.InvalidOperation without further description
Is there any tools(free) that I can use to get more specific information on what goes on
I am not sure how/if you can debug the application, but here is another idea.
There are tool out there called "reflectors", which allow you to look inside the .NET dll or executable.
They basically do the reverse of the compiler convert the dll/exe to source code (Now it won't be exactly the code you wrote, for example some local variables might have changed their names and some things might have been optimized, but the end result is the same, since this reflected code came from the same dll/exe.)
Now you can take the output of this and use it to rebuild and then debug your application.
Here are some ofthese tool:
dotPeek - free
.NET Reflector - not free
I know dotPeek doesn't allow you to debug inside of it, so you have to rebuild your application. The other one seems to be able to do that with its most expensive licence. Good luck!
You can also use Microsoft Debugging Tools for Windows (WinDbg). Here is an article that can help you.
http://www.dependencywalker.com/ will tell you dependencies and missing ones.
Also, you can attach visual studio, or get visual studio to launch a exe in debug mode without the source code.
my first try would be dependency walker just to make sure your not
missing some piece of native code
then I would look to just attempting to attach the program to visual
studio.
My next step would be to use something like reflector to get some
version of source code.
The pro version of regate's reflector let's you debug an existing dll without the sourcecode, costs $ 138 tho.
Ilspy will let you see the source for free, maybe you can figure it out from that.
Rgds Gert-JAn