Visual Studio unable to load necessary dll's to run project - visual-studio-2010

I am trying to run a project in Visual Studio 2010, and for some reason it seems like I can't... the command-line window is closed instantly and the debug info is the following:
'exercise01.exe': Loaded 'E:\e\work spaces\C++ projects\exercise01\Debug\exercise01.exe', Symbols loaded.
'exercise01.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', Cannot find or open the PDB file
'exercise01.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', Cannot find or open the PDB file
'exercise01.exe': Loaded 'C:\WINDOWS\system32\msvcr100d.dll', Symbols loaded.
The program '[5900] exercise01.exe: Native' has exited with code 0 (0x0).
what might be the cause for these two dll's to not get loaded? and is the fact program exited with code 0 related to my program not running, or is there another problem?
I know others have published such questions before, but unfortunately I couldn't fine any useful info anywhere, so forgive me if I'm re-uploading a question... I'm pretty much a noob when it comes to programming in C, and in Visual Studio in general, so please have patience (:
thank you :)

First thing to check: Are these files actually there. Maybe windows is installed in a different directory and an environment variable is pointing to the wrong place.
If the files are there it is probably an authentication problem. You are running from the command line window. You may be running this in the context of NETWORK SERVICE. Try starting the command window, by right clicking on the menu and selecting "run as administrator".

Basically, your program was started and quickly ran to completion.
When you start debugging a console mode VS project, if your program doesn't stop somewhere or hit a breakpoint, it'll just run the program and when the program exits the window will close.
This is different behavior than if you run the program without the debugger - VS will keep the console window open when the program terminates.
Anyway, you can wither set a breakpoint on main() (or some other convenient location) or instead of simply starting the program with the debugger, you can "single step" into it, which will immediately break into the debugger and stop executuion.

Related

How can I disable Fakes.exe running when I break into debugger?

I have recently started creating some tests in a solution which make use of the Microsoft Fakes framework. All good there, however I've now noticed that when I am debugging my main program (not the tests themselves) and break into the debugger, I have to wait a considerable time.
When I look at Process Explorer I see Fakes.exe running;
"C:\Program Files(x86)\MSBuild\Microsoft\VisualStudio\v12.0\Fakes\fakes.exe" #D:\some\path\My.Tests\obj\Debug\Fakes\fakes.args
Any idea why this is happening when I debug the main program, and how I can prevent it?

Debugging Spawns A Non Terminable Process, and CLI not launching

I've been fighting this little problem for a while now, so I'm really hoping I can get some help. I've been looking for a solution to this, and I found this SO question: Debugging doesn't start.
My issue is somewhat similar to the issue discussed here, except that my issue is a two-parter.
Part 1: Similar to the issue discussed on the other question. (Debug Window Doesn't show up)
When I attempt to launch my Windows 32 console application project (The simple kind that opens in the windows CLI). The CLI (or CMD) window doesn't open, and windows idles giving me a spinning cursor wheel. Visual Studio IDE (I'm using VS 2013 Community) becomes unresponsive and I cannot access any menus, or use any hotkey to "Stop Debugging". One difference from the provided SO question though, is that when I try to launch "MyProject.exe" from my project's "Debug" folder I get the same result as attempting to debug in the IDE.
Part 2: Unkillable Process
When I try to close my debug application in the windows task manager, it is not listed as an ongoing process. However, whenever I try to manipulate, delete, or otherwise modify my Project.exe application (in my Project's "Debug" folder), windows informs me that the application is in use. Confused by this, I downloaded two applications. The first was Process explorer, which showed me that I did in fact have 2 instances of "MyProject.exe" running. The second was Process Hacker, which also showed me 2 instances of "MyProject.exe". However, neither of these programs were able to terminate either of the "MyProject.exe" processes.
I am capable of terminating the processes for visual studio and restarting the IDE, however, because the "MyProject.exe" processes are still running. Building always fails with the error
"Error 1 error LNK1168: cannot open C:\Users\Brandon\Desktop\MyProject\Debug\MyProject.exe for writing"
Whenever I restart my computer, the lock files (as expected) are removed, and the "MyProject.exe" processes disappear. I can restart VS and everything works, but if I try to Debug (pressing "Start Debugging" or F5) the same issue occurs.
A process of my program is started ("MyProject.exe"), but the CLI window where my program's text should appear doesn't show up. Visual studio locks up, and "MyProject.exe" persists until the next restart because "MyProcess.exe" cannot be terminated.
My solution configuration is set to "Debug", Solution Platforms = Win32.
I have tried creating a new blank console project in VS 2013 and I get the same result: code builds fine, but I have the same debugging issue. I get an identical result with a quickly assembled "Hello World" project.
Sorry for being a noob, but honestly. I really don't know what's going on, so any help is greatly appreciated.
(Note: Running Windows 10 with VS2013)
EDIT (UPDATE):
So, I'm having the same problem with several programs in Windows 10 (most notably Allegorithmic's Substance Painter). So it looks like this may actually be an OS problem. Several of my programs whenever I try to launch them do the same thing...the program acts like it's going to launch, but then no usable window appears. Looking at my processes I can see that the process has been started, but it is once again unkillable. For reference, I am using Windows 10 Version 1511 (OS Build 10586.17).
I believe your problem might be Avast, if you are running it. I had exactly the same issues until I uninstalled it. Had upgraded to Win10 and VS2013 just froze, same as you described.
Cheers.

ClickOnce Program Not Starting

For some reason a ClickOnce program I made in VisualStudio will not run. The program runs normally if I compile it, and I have made ClickOnce programs in the past that have run on my computer, so I know it works. I get no error messages, and the program never shows in the Task Manager. Any ideas what could be wrong?
EDIT: I found the problem. It wasn't including some text files that my program opens and reads when it starts. I'm guessing the program terminated when it didn't find those files, but why did I not get an error message pop up?

How to break a process on start

With visual studio you can attach to a running process, hit 'pause' (or called break), and even without symbol files or source, you've paused the process and can see a disassembled view.
I would like to achieve this but at the very start of the process. Attaching and pausing as quickly as possible is not the solution I'm looking for :)
For example, if the application was a console based c++ app, gdb can set a break point on main() [or any named function it can find for that matter]. Can something similar be done with visual studio?
But this question is for the more general case - I'd like to be able to start a process and have it pause immediately upon entry (immediately after the kernel launches the process).
http://blogs.msdn.com/b/greggm/archive/2008/09/12/attaching-a-debugger-at-startup.aspx
There are some level of support. But if I were you, I would use WinDbg directly.

Visual Studio: No disassembly available

I want to run the Visual Studio debugger on a .Net program that has been obfuscated. (It's my own program - I'm not trying to crack someone else's program.)
When I compile the program with "System.Diagnostics.Debugger.Break()", or if I attach the debugger to the running process, then the debugger shows "No Source Available". This I understand - there is no source that corresponds to the obfuscated version of the program. But when I click "Show Disassembly" it shows a Disassembly window with "No disassembly available."
Why? Any suggestions as to what I can do to get the disassembly to work?
Under Debug Options I do have "Enable address-level debugging" and "Show disassembly if source is not available" checked.
Thanks.
EDIT
Just to try to explain a bit more ...
The program in question is my own program, and the obfuscation program being used is also my own program. The obfuscation program runs ILDAsm.exe, modifies the ILAsm code, and runs ILAsm.exe.
My obfuscation is apparently introducing problems so the program no longer works correctly. To understand how/why it isn't working I'd like to trace it. But for some reason Visual Studio debugger says "No disassembly available", and then I can't do anything at all. (When the non-obfuscated program is run under Visual Studio the Disassembly window can be opened and shows the expected information. It's only the obfuscated version that produces this problem with VS debugger.)
EDIT 2
Haven't been able to find an answer to my question, but I do have a sort of workaround now.
I've installed WinDbg and confirmed that it can attach to my obfuscated program and can at least single-step it and show the current execution location in a disassembly window. But I've never used WinDbg before, and it looks a bit daunting.
I've also followed the advice seen several places to load sos.dll into WinDbg. Maybe that will help.
But I'm guessing that what I'll actually end up doing is throwing lots of temporary logging statements into my program around the places where it's not working, and hopefully gain some understanding that way.
OK, I happened to stumble on what I was doing wrong.
As I mention in the first edit of my question, my obfuscation is being done by running ILDAsm.exe, modifying the ILAsm statements, and then running ILAsm.exe. It turns out I was missing the /Debug option on the ILAsm.exe run. So even though my Visual Studio builds were Debug builds, the JIT conversions at run time were Release/Optimize conversions.
With /Debug specified on ILAsm.exe I'm getting a PDB file, and when Visual Studio debugger connects to my program I'm getting IL source code display and, if I request it, disassembly display too! So now all is well!

Resources