If I create a new console application (.NET Framework 4.5.2) and enter the following lines as the complete contents of the Main method:
Console.WriteLine("A");
Console.ReadLine();
When I hit run (F5), VS enters debugging mode and shows the memory usage graph but does not show any console window. This same problem is seen on every console application I try to use in VS2017. While not universally the case, in the app I described above, running this by double-clicking the .exe file does produce a console window.
Does anyone know how to get VS2017 to show a console window?
This appears to be to do with 32-bit applications.
Unticking the prefer 32-bit option in the build options solves the problem.
Edit: Further investigation showed this to be a problem with an extension used within my company. Disabling this extension let my console windows appear again.
We have configured WER (Windows Error Reporting) to create dumps every time some applications crash.
It normally works but we have found several scenarios where it does not work. We will take as an example Winword.exe:
On some cases the process simply disappears. No window, no event log, no crash dump. Nothing.
On other cases a window telling you that the application has stopped working appears but automatically the application gets restarted and no crash dump is generated too.
Other times the application ends as expected with the "Application stopped working" and it works normally.
Any idea about why this happens and how to trap these crashes and generate a dump?
I've associated my Windows 8 App with a file type. However when I open that file my app starts to open and then crashes.
I can't figure out a way to do this while the debugger is attached.
I assume there is something wrong with my OnFileActiavted method so I've resorted to changing random bits of code in that method. This isn't working, so I'm wondering how I should debug this problem.
Does this work? You can debug without launching the app immediately. You can also debug other people's apps.
Another approach:
Debugger.Launch();
When your app starts and execution reaches this line, your app will be stopped and VS will ask if you want to attach a debugger.
If a VB6 app is causing an Application Hang event to appear in the Event Viewer, how can I find out more about why the application is hanging?
Does an Application Hang event mean that the app has frozen and crashed, or just that it temporarily hangs?
All I get in the event log for this event is:
Hanging application [MyAppName].exe, version [MyAppVersionNo], hang module hungapp, version 0.0.0.0, hang address 0x00000000.
That is not enough and I want to be able to find out more about why it is hanging. What code changes or other steps need to be taken to cause the app to provide more details in the event log?
I recommend using the Windows Performance Toolkit. The best version to use is in the Windows Assessment & Deployment Kit, http://www.microsoft.com/download/en/details.aspx?id=28997
Once it's installed, what you do is start up Windows Performance Recorder (WPR) and click the Start button to begin recording. Next, reproduce the problem with your app. Then go back to WPR and press the Save button. Next, load up Windows Performance Analyzer and open that *.ETL file that was generated. Then you want to go to System Activity section in the Graph Explorer, expand it, and find the UI Delays graph (or it might be the first graph parked on System Activity). Double click on it to get the detailed version in an Analysis tab.
Once you find the UI delay you're interested in, you can add another graph such as CPU Usage (Sampled) from the Processing node in Graph Explorer. When the two graphs are in the same Analysis tab, their scrolling and selection will be synchronized. So you can click on the UI delay event and it will also highlight the corresponding range in CPU Usage.
The Application Hang event means that Windows has decided that the application is unresponsive. Since the event is generated by the operating system and not the application, your options for getting additional information in the event are extremely limited.
This is what seems to be available on an Application Hang event:
Message: Hanging application %1, version %2, hang module %3, version %4, hang address 0x%5.
From:
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=1002&EvtSrc=Application+Hang&LCID=1033
If you believe the cause of the event is something that your application does (as opposed to something in the environment where the application is running), then instead of trying to pass info to the hang event, you should raise the level of log info to debug mode and look in your application's log file to see what it is doing just prior to becoming unresponsive.
If you lack logging information, or a logging framework in your application, then that is where you should be focusing your efforts. The upside is that you will benefit from better logging in the future as well. Use a logging framework however, so you can disable debug level logging in a production environment, when everything is running smoothly.
I would approach this by reviewing the code in the module that Windows has determined has hung, the name of which was written to the event log. Attempting to get more detail in the hang event will not be possible because when Windows has determined the app is unresponsive, it is too late.
Into the module that is hanging I would add multiple calls to DoEvents as well as logging status messages directly into the EventLog. Adding a logging framework at this point would introduce complexity and involve either a database or file access in which to store the logs.
Windows thinks the app has hung because it has stopped responding to messages. Unfortunately, implementing a second thread in your VB6 app is not trivial, unlike .NET. Never-the-less, adding another thread would keep the app responsive, but then you would likely still be left with answering the question, "why is the code taking so long to execute?"
Getting information from windows event perspective will not help. Try to have tracing in your application which helps you to get the exact cause.
I have a .NET Windows service that appears to be crashing due to C00000005 (access violation--according to Dr Watson). When I attach the VS debugger to it--whether I build it with or without symbols--the VS debugger just stops when the service crashes, instead of stopping to give me a chance to do any investigation.
Is that to be expected, or am I doing something wrong?
Will using WinDbg let me do something more in real time (obviously, WinDbg lets me do crash dump analysis)?
Thanks!
You should go to the exceptions window (Debug -> Exceptions) and select the Thrown check box for that exception in the Win32 Exceptions. Moreover, pay attention that you are debugging Native Code (see the attached to combo box in the attach to process window.