From time to time my 32bit .Net program hangs the entire windows 10 OS. I am unable to get to task manager or a console on the computer to do a dump of my .Net for analysis in windbg. We have tried RDP, RDP to console, remote command line - but no luck accessing the computer - we just have to reboot.
Is there a way to get a Windows 10 diagnostic dump when the OS hangs, and then analyze this as a .Net app in WinDBG? Note: my app is 32bit and dumps created for 64bit apps dont work for my app in WinDbg.
thanks
Unfortunately, if you your windows machine is frozen and is not responding to any input device (keyboard/mouse), the only way to get a dump from that machine is to set up windows kernel debugging.
You will have to follow the steps described here. Once your machine is setup for kernel debugging, and you have verified that you can break into the kernel of the machine where your program is running, wait until the machine is unresponsive and then break into the machine.
This will allow you to examine what windows is currently doing. There is a little bit of learning curve to set up the debugger and use windbg kernel debugging but this is the most powerful debugging environment that windows offer. You can download windbg here. It comes with comprehensive documentation.
Related
I have created a WPF desktop application using the community edition of Visual Studio 2017.
The problem that I am facing is that my application does not run on some PCs where I try to install my application whereas it runs fine on others. On the OCs where it does not work, when I execute my application no errors are thrown but in the task manager the status of my process changes to suspended and then the process is removed from the set of running processes.
I am able to debug and run application on my PC (Win 10 64 bit OS), and on couple of other PCs that have Windows 8 64 bit OS, but the ones on which the application fails to run are Windows 10 PCs, but I am not sure if Win 10 is the problem since the application is running on my PC.
When creating the installer for my application, I have the following options selected:
.Net framework 4.6.1(x86 and x64) as a pre-requisite.
Download prerequisites from the same location as my application.
I need help in debugging what is cause for this problem, since at this point I do not know what is stopping my application from running. How can I debug what is going wrong on these deployment PCs?
I have tried installing on different PCs, but could not identify the reason why it is working on some whereas not on others.
I thought maybe the "Microsoft Visual C++ Redistributable 2017" is a requirement so I downloaded and installed on the client machine but this too did not help.
I also disabled the anti-virus software, but this too did not help.
I have a Raspberry Pi v2 running Windows 10 IoT and am trying to run a dotnet 2.0 console application on it.
I have a powershell script start it on startup, but then I do not get the console output from it. I was wondering if there was a way to attach to the running process with powershell on my computer, like you would to a docker container, to get the console output.
I do not want to run my program on my computer, and the Raspberry Pi is the only computer I want to leave on overnight to run the program.
If you can't or don't want to re-start your Application
You are rather limited in this case, since, as stated in another SE Answer by Harry Johnston:
Windows does not provide any mechanism to retroactively give another
process a standard output handle if it was created without one.
(Besides, in most cases an application will check the standard output
handle only during startup.)
If you need to read something that already has been written to the Console, you are probably out of luck.
You should however be able to get any future output by attaching to the process with debugging tools.
In case of the Visual Studio Remote Debugger, this would even allow you to debug the execution of your Console Application, provided you wrote it.
An accepted answer on Superuser.com suggests that StraceNT is also capable of read the output of a running Console Application. This will probably be your best bet if the running Application wasn't written by yourself.
If the Application can be stopped and restarted
Powershell Remoting is probably the best way.
You would need to enable Powershell Remoting on your Raspberry Pi, and then you can use enter-pssession [RaspberryPi-Hostname-or-IP] in your local Powershell console to connect to your Raspberry Pi.
At that point you can just start your console application as if you were running it on your local machine and get all the console output you want.
No need to attach to anything.
You can redirect the output of your console app to a txt file in the current directory. If you run the console app from powershell you can do it like this:
.\[YOURAPP].exe | tee test.txt
And you can access the test.txt from Windows file sharing.
I'm moving from Windows CE 6 to Windows Embedded Standard 7 for a project and am wondering how remote debugging of .Net apps works with Windows Embedded target devices. In CE with VS2008 and ActiveSync (USB), I can hit F5 and my app is automatically deployed to the target device and executed so I can step through my breakpoints just like I would if I were debugging locally.
Is there an equivalent remote debugging solution for Windows Embedded debugging? A quick glance through the Visual Studio "Remote Debugger" documentation makes the whole thing seem a lot clunkier/less integrated. Is there an easy way to debug applications on target devices running Windows Embedded like I would with CE?
Thanks,
Ben
I only have experience doing this over standard network interfaces on a Embedded Std7, but I guess the approach using an ActiveSync connection is exactly the same (as ActiveSync devices like my cellphone turn up under 'My Computer'); in short:
suppose the Embedded device is on \\Embedded
share a directory on the Embedded device, say 'temp'
start the remote debugger client on your device
point the output directory of your VS project to \\Embedded\temp
set the options for your project to remote debugging on \\Embedded
hitting F5 will build the exe, put it in \\Embedded\temp and start debugging it
Look here for the document that got me started.
mono : Is remote debugging possible with monodevelop? I want to remote debug a console application running on a remote RHEL server with monodevelop installed on CentOS development machine. Is this possible with monodevelop?
This could actually be done with the Soft Debugger.
Currently, no. This is not possible. I have heard the MonoDevelop team mention they would like this feature in the future, but I do not believe they have a schedule yet for when they will get to it.
The new Soft Debugger and the MD addin do support remote debugging but there's no way to set up the debugger session from within MD (except for iPhone apps).
Also, despite its name, the MeeGo addin supports remotely running and debugging apps on any GDM-based Linux machine over SSH. It could easily be modified to support machines without X, or running different project types.
http://anonsvn.mono-project.com/viewvc/trunk/monodevelop/extras/MonoDevelop.MeeGo/README.txt
I'm doing something bad in my ASP.NET app. It could be the any number of CTP libraries I'm using or I'm just not disposing something properly. But when I redeploy my ASP.NET to my Vista IIS7 install or my server's IIS6 install I crash an IIS worker process.
I've narrowed the problem down to my HTTP crawler, which is a multithreaded beast that crawls sites for useful information when asked to. After I start a crawler and redeploy the app over the top, rather than gracefully unloading the appDomain and reloading, an IIS worker process will crash (popping up a crash message) and continue reloading the app domain.
When this crash happens, where can I find the crash dump for analysis?
Download Debugging tools for Windows:
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
Debugging Tools for Windows has has a script (ADPLUS) that allows you to create dumps when a process CRASHES:
http://support.microsoft.com/kb/286350
The command should be something like (if you are using IIS6):
cscript adplus.vbs -crash -pn w3wp.exe
This command will attach the debugger to the worker process. When the crash occurs it will generate a dump (a *.DMP file).
You can open it in WinDBG (also included in the Debugging Tools for Windows). File > Open Crash dump...
By default, WinDBG will show you (next to the command line) the thread were the process crashed.
The first thing you need to do in WinDBG is to load the .NET Framework extensions:
.loadby sos mscorwks
then, you will display the managed callstack:
!clrstack
if the thread was not running managed code, then you'll need to check the native stack:
kpn 200
This should give you some ideas. To continue troubleshooting I recommend you read the following article:
http://msdn.microsoft.com/en-us/library/ee817663.aspx
A quick search found IISState - it relies on the Windows debugging tools and needs to be running when a crash occurs, but given the circumstances you've described, this shouldn't be a problem,