I'm having a really strange problem that I just can't figure out. Things I compile in Visual Studio 2015 (C# projects in WinForms and WPF) will not launch outside of Visual Studio. This includes a project that is completely new and untouched. As in, create a new WPF Application, build in debug and release. Go to containing folders click on EXEs and...nothing.
When I run them I get 3 processes appearing in Task Manager (named the same as my application) than cannot be killed (through task manager or command prompt) and nothing else occurs. Nothing in event viewer that seems to correspond to the app. I've attached an instance of VS 2015 to the process and I get the following message: WpfApplication.exe has triggered a break point. Pressing Break takes me to a screen that tells me no debug information is available and pressing continue has no visible effects (I can occasionally see slight movement in the cpu % but not a lot else). Any attempt to stop debugging will cause visual studio to hang and when I end its process VS closes but its memory is not freed up according to Task Manager. All of these same things occur when building in VS2013 and attempting to run outside of VS. Everything runs just fine when run in debug mode inside Visual Studio but outside of it...not a chance.
I literally have no idea where to proceed from here. I can find no error messages or clues to point me in a direction to look. Is there something I'm missing/doing wrong? What steps can I take from here to find the source of the problem?
I've considered it may be something wrong with my computer but I want to explore the possibilities before I do something drastic like a clean install. If the prevailing opinion lies that way then I'll seek help elsewhere!
tl;dr: launching the exe of a compiled application results in no running application and no obvious error messages, how can I proceed from here?
I'm going to post an answer to this because I found out what was wrong but it probably isn't useful to have it hanging around so I'll just delete the question at some point soon.
The main lesson to remember is that the main purpose of anti virus software is to frustrate you as much as possible and if something weird is happening try turning it off briefly and see what happens. You'll probably find that things are now working correctly.
EDIT: I should restate this in a more serious fashion.
Anti virus can sometimes affect things in unexpected ways and turning it off temporarily can save you a lot of time. Keep it up to date too, mine was a version or so old and was not functioning correctly. I updated it and the deep scan now functions as expected rather than silently failing.
Related
I am working in VisualStudio 2010 SP1 on an application server system written in C#. (Yes this is a legacy application.) The system is a large multi-threaded server application that provides a large SOAP API along with newer REST APIs for other portions of the system.
For a long time I have noticed that occasionally when starting the system in debug mode both the server and VisualStudio would stall. Neither UI would respond and calls to the server APIs would block. This situation could be recovered from only by halting the server using Task Manager, after which VisualStudio would complain with an error.
Recently this problem became persistent, that is it happens every time. The lock up occurs at various times, that is I have not been able to identify a specific time when the system locks up, it may (often) happen as soon as the server is started, other times it may take a minute or so, but always shortly after startup, both VisualStudio and the server lock up.
If I try to do something in the VisualStudio UI, e.g. pressing the Pause button, I will get the "Microsoft Visual Studio Delay Notification" icon in the notifications section of the Windows task bar.
I have done some investigation on the web and have tried the following unsuccessfully:
Clean rebuild
Removing all build products from the directory structure
Doing a clean checkout in a new directory structure
resetiis
Removing the .suo files
Resetting the VisualStudio settings
I have also tried creating both mini & full dumps of both the application and devenv, but I have not been able to understand them well enough to find any issue.
What would you do to try to identify the issue?
The solution to my issue turned out to be working on the program using VS2015. This is not a wonderful solution since we still build in VS2010, but it at least allowed me to proceed. We are not sure exactly what caused the issue.
whenever i use xaml editor designer mode, there will be an instance of XDesProc.exe at Windows Task Manager and it consume very high memory that eventually make the application hangs while i debug.
What I usually do is i will kill it at Task Manager and the program can continue running but designer view will be gone. This problem only exist at particular project but I've no idea where to trace the problem. Any wild guess?
These things to attempt or keep in mind.
Is the latest update for visual studio installed? Even if it is, one may want to run it again and try Repair.
Look at the controls on the screen in question. Can checks to determine if in design time such as DesignerProperties.GetIsInDesignMode(this) be used to circumvent code which shouldn't be run in design time? Check constructors for such places to put that check.
Remove the controls one by one until the designer behaves normally (or within a reasonable speed). That may give you a direction on the issue.
Does the same happen in Blend?
Run it in Visual Studio 2015/Blend 2015, do the same things happen? Note, if money is a factor usage of Visual Studio Community 2015 edition will work.
I have a c# winform application, when I run it from Code, from Visula studio, It works well. But when I built exe for the same and running the same Hangs after working well for some time even it shows 0% CPU utilization in Hang state.
Hoping for a little help for solving the same problem would be very much useful from PRO people here.
Even a pro would have a pretty hard time diagnosing the problem without even a single line of code posted.
But that's okay: we can help you help yourself. :)
Run the program without Visual Studio, wait for it to hang. Then start up Visual Studio and use the "Debug/Attach to process..." command to attach the debugger to the hung process, pause execution, and take a look at what it's doing (or not doing).
There is a program where I work that works fine when running the .exe file but works differently from expected when opened in VS2005 and played from there. I am therefore asking on here if anyone knows of anything that would work in the .exe file but not the debug from VS? I am not able to post the code for the buttons I'm talking about but I'll try to explain the best I can.
There is a receiver hooked up to the computer. When the button is pressed on the program, it shows a message and waits for a signal to be received. After the signal is heard the first message box is supposed to close and another is supposed to open. When using the .exe file this happens just fine. However when playing from the program from VS2005 (the same one from which the .exe was made) the second message doesn't come up when it is supposed to and when I can make it come up, the first box doesn't close. There is also a timer involved if that helps.
Also, is there a fundamental difference between how the two operate when executing the program?
If I need to make anything more clear or give more details please let me know.
Running a program under the supervision of a debugger can change the timing of events compared to running the program standalone. The debugger slows things down. Normally, this doesn't make any difference to the operation of the program, but if you have code that is dependent on the "coincidental" rapid timing of some activity, that happy coincidence may be broken when things slow down under debugger control.
The debugger can also cause changes in focus and activation depending on where you set your breakpoints - generally not a good idea to set a breakpoint in focus change or activation events because stopping at the breakpoint will change focus to the debugger, away from your app. But these are interaction issues. Just running your program under the debugger with no breakpoints shouldn't affect focus or activation in your app.
Review your code carefully. Consider what could happen to your program flow if you inserted delays between every source code statement. If that could lead to problems, you have a design bug that needs to be fixed. Reliance on coincidental timings will lead to bug reports and support calls, particularly if your customers have slower hardware than your development machine.
When you run under the debugger, or even in the VS testing host, there are some subtle differences. This shouldn't effect your program under normal circumstances, however, since most of the differences are similar to running (the debug version) of your application on a slower system.
Given your descriptions, I suspect that your problem is actually due to calling to the UI from a different thread than the control was constructed with. Make sure to always marshal any calls to the UI using Control.Invoke or Control.BeginInvoke.
It may be an issue with the Host Process, disabling it is a painless click and just as easy to re-enable. It may be worth giving a try.
Disable Host Process
I know this can effect Direct X and other API but I've never had exactly the situation you are in so I make no promise.
Is it possible to rise a cmd.exe processes from the silent background mode to the visible foreground so I can LOOK at them?
Problem Background:
I'm using VS2008 working with a very large solution containing C#, C++, and Fortran. Occasionally (a few times a day) when building my project the build hangs and does not allow me to do anything in VS (resulting in the need to kill the process). I have checked the output box, and there appears to be nothing helpful there.
Possible Cause:
I am thinking that maybe one of the cmd.exe windows that are spawned in the background may be waiting for some form of input, but to investigate I need to see those windows.
Search for Other Causes/Solutions:
If not this, is there a way to try to check and see if there is something else going on? Is this a problem anyone else is having. (Note: killing VS and reloading often fixes the problem first try, and the build process takes less than 15 seconds.)
If stopping and restart fixes the problem, I guess it's not an input problem.
For example when my build project halts, it's always the VB6 project or SVN that are upset. (strangely the VS projects always work fine).
Once one of these halt, they halt until they are fixed. Thus for the VB projects run and work-out what the model dialogue is saying and fix it. or on SVN it usually need a clean-up run on the directory.
The intermittent nature suggests some sort of timing issue, like a file been lock open etc.
You could attach another copy of visual studio to the cmd.exe and see where it's at. Not sure if you can get symbols for it, so it might be fun to diagnose.