This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Service runs then dies.
Hello,
I'm running Win 7 Pro 64-bit. I wrote a service in C# using the .NET 4 framework. It installs properly and starts to run. I know that it runs because it writes some output to a log file. However, after a few seconds it dies. When I use Visual Studio 2010 Pro to run this same code not as a service it never dies. So, my obvious question is regarding the appropriate approach for debugging this since I can't figure out why it should dies as a service but not die as a non-service. I've put writes to the log file in several places in the code but it seems to die in a different place every time. The application has 3 threads. Any suggestions are welcomed.
Thanks,
Ray
I suspect some sort of thread unsafe code. This is a typical symptom of code that is not thread safe. At some point two or more threads crash into each other (such as when one iterates a list, and another modifies that list).
When you are doing debugging in VS the code runs significantly slower, so it is less likely/takes longer for the threads to crash.
Related
I have a new Win10 laptop. I've installed lots of software, including a 25-year-old Codewright editor that I've customized up the wazoo, and that I've been installing on all my machines for, well, 25 years. After working for a few days, it suddenly stopped, and reinstalling it didn't fix it. On startup, it puts up a small splash window, and normally opens the main window a half a second later (that took more than 5 seconds 25 years ago). It's not using any CPU, and there's nothing I can do but kill the process.
In the past, I've occasionally got my system into a state where Codewright would hang on loading, due to some other program that hadn't terminated correctly, and it was unfrozen by killing off that other process. So that's reason to believe that Codewright is waiting at some global lock which some other malfunctioning software is holding. So I have two questions:
Does this ring a bell? Is there some known failure mode where a program putting up a splash window then switching to another window can be prevented by something else going on the system?
Is there a way to diagnose this, perhaps by finding out what system call it's hanging inside? I tried dtrace.exe, started Codewright, and then stopped tracing, and it produced a 3GB XML file, which is quite a haystack. There's a way to filter it by PID, but since this is a startup problem, I have no idea what the PID will be. Is there a better tool for doing this, or some more appropriate dtrace feature that I missed?
The comment about using the Task Manager to create a dump file actually led me to notice that there is an Analyze Wait Chain function there that I had never seen before, since I haven't used Task Manager much since I switched from Win7. This gave me exactly the answer I wanted. My editor was waiting for something that was being held by some NVIDIA GeForce Experience module. Since I don't use that, I uninstalled it, and I'm back up and running. Thanks for the tip.
This question already has answers here:
debugging a process spawned with CreateProcess in Visual Studio
(3 answers)
Closed 7 years ago.
I have a program running which loads up a separate program to do some work for it. That separate program is run from the first, using Process.Start() and I need it to load into the Visual Studio debugger to single step through it.
Unfortunately, though I can run the first program in a debugger session, it still starts the second as a "proper" process. I need to have this second program open up in a debugger session. Normally I would just attach a debugger to the process once it's started but, in this case, I need it to breakpoint very early on (in the CInitDialog() function) and, as fast as I am, I can't outrun the code in this case.
A solution I found right here on Stack Overflow said to use Debugger.Launch() but that appears to be specific to C#.
I also thought of trying to cause a crash in the code (such as with a null pointer reference) to load up the debugger but I suspect this would mean single stepping would then be unavailable to me.
How can I do this?
Visual C++ has a similar feature to the C# Debugger.Launch(), it's called DebugBreak(). This actually breaks the application and it will present you with a dialog box asking how you want to handle it:
If you select Debug the program at that point, it will then ask you whether you want to do it in a new Visual Studio session or an existing one. I tend to have the solution already open so I can effectively attach to that one - opening a new instance gives you just the file rather than the entire solution.
So you can simply insert that call in your code where you want to break, and allow the first program to run it as per normal. The second program will start up and break where you've placed the statement and you can then single-step and do all the other wondrous things a debugger allows.
This question already has answers here:
Debugging with command-line parameters in Visual Studio
(13 answers)
Closed 8 years ago.
I am debugging an application someone else wrote which runs as a Windows Service unless it is started from the Console and passed parameters. I would like to start this program from the Console, including some parameters, and then step into the debugger. I'm not sure how to do this since before I execute the command to start it, there is no process to attach to, and once I execute the command, it's too late to catch it (errors begin almost instantly). I'm trying to figure out if there's a way in Visual Studio to set up the debugger to attach to a process before it's actually running (or perhaps something effectively similar, given the description of my problem).
I have a breakpoint on the very first line of Program.Main and I'm essentially trying to figure out how I can launch the application from the Command Prompt and then immediately hit my breakpoint. Is this even possible?
I'm running VS 2013 on Windows Server 2012 Datacenter, by the way.
I think that you don't need to run this program from console - just run (start debugging) it with parameters. Here there is similar question, it should solve you problem. Note that if for some reason my advice is not a good solution for you, you can use solution from second answer (from link) - it's exactly what you are asking for.
I have a .NET project that I've been compiling with Visual Studio and running successfully on Windows for years. I'd like to move to use Mac OS X to run this particular program, and so have been working with mono for just a little while do make that possible. The results have been excellent, with the program performing as expected under mono (2.10.9, BTW).
The only hitch is that the program does not exit after it is done. It is a single-threaded process, but when its work is completed (which it reports at the end of the Main(string[]) method), the process does not exit; ^C is required to return to the shell prompt. Adding an explicit System.Environment.Exit(exitCode); call at the end has no effect.
I found only one other tale of this sort of problem from some years ago, here, though that ML thread provided no potential solution.
Rolf (in his comment on the question) was right, the vm was deadlocking upon shutdown.
I'm using IKVM in this application, and there are certain circumstances where it needs to start a thread at vm shutdown to clean up its JVM<->CLR interop machinery; this apparently does not sit well with mono (but always works in .NET).
This was discovered on a thread on the IKVM dev list by IKVM's author, who filed this bug with the mono project.
The workaround in my case was to explicitly call java.lang.System.exit(exitCode) instead of simply letting the program terminate naturally or using System.Environment.Exit(exitCode). This allows IKVM to shut down outside of the vm termination lifecycle, thereby avoiding the mono bug.
This question already has an answer here:
Closed 11 years ago.
Possible Duplicate:
Windows Program: How to snoop on command line arguments?
I am working under Windows XP.
I've been given some third-party software that spawns several processes when launched. I've been tasked with writing a replacement for this software, though I will need to keep one of its proceeses (a "communication server" that passes / receives messages to / from identical "communication servers" on other networked machines). One small part of this process is learning to start the "communication server" directly. If I just start it with no arguments from the command line, it immediately dies. I'm thinking it needs some arguments. So, all my question boils down to is...
Is it possible, for any arbitrary process, to see what arguments it was started with? If so, how may I do so?
I tried attaching Visual Studio 2010, but there's no .pdb, so I got nothing. Unfortunately, I do not know what language this "communication server" is written in. So, it was really a longshot. (I wasn't sure if doing so would give me a way to find the arguments anyway, but I thought it was worth a try.)
Thanks,
Dave
P.S. Sorry for the poor choice of tags. This is a tough one to categorize...
Process Explorer displays them. Right click on a process in the list, then Properties... -> Image -> Command line
It's not 100% reliable since the process can overwrite the buffer containing the command line, but usually it works.
Process explorer will allow you to see the command line arguments for a given running process :)
You don't need the PDB for the app itself. Windows DLLs have PDB's; put a breakpoint on CreateProcess and variants like ShellExecute / CreateProcessAsUser.