My winform application crashes as soon as its been launched. This problem is only happening in one of the client computer. Works fine for all other clients. I was thinking of using ADPlus to get a crash dump but problem is in order to configure ADPlus in crash mode, debugger need to be attached to running application first. That means application must be running when I configure ADPlus, however, as I said my application crashes as soon as I start it. It does not give me a chance to run ADPlus. Any idea if ADPlus can be used in this scenario? Are there any other tools that I can use generate a process dump in this case?
Since you can't start the program and then attach a debugger in time, you can try one of the following ideas:
Start the program under the debugger on the machine where it's crashing. As already mentioned, ProcDump is enough for that purpose, or you can use Visual Studio or WinDBG.
If you can't easily start the program under the debugger (for example, if it is actually a Windows service), use gflags to make Windows start the program under the debugger. This will create a subkey for your program filename under the Image File Execution Options registry key.
Set your debugger as the postmortem debugger, so it always launches when any program crashes.
If and when the crash happens, the debugger will automatically break in and either create a dump automatically or let you create one manually.
If you can't run a debugger, not even ProcDump, you can use Windows' built-in crash dump facility to create a dump automatically:
On Windows XP and Windows Server 2003, set Dr. Watson as the postmortem debugger by running this command:
drwtsn32 -i
Here is info on what this command does and how to use Dr. Watson: Capturing Application Crash Dumps
On Windows Vista SP1, Windows Server 2008, and later, set Windows Error Reporting to save dumps locally by creating this registry key:
HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
You don't need to create or set any values or subkeys under this key. If you want to change settings, here is more info: Collecting User-Mode Dumps
Note that "applications that do their own custom crash reporting, including .NET applications, are not supported by" WER. This is a problem for you because your app uses WinForms - although there is some indication that the feature does work with .NET 4 apps on Windows 7.
You can use ProcDump from Sysinternals to capture a dump.
Related
I have the following scenario:
Windows 2008
A Service running running with a specific user credential (i.e. not the System Account).
That service starts a child process
The child process starts, gets an exception after a second and crashes
I am trying to attach a debugger to the child process and debug it before it crashes
I was trying to use gflags and set the debugger. Problem is that the service is running in session 0 hence Windbg is not viewable. I cannot set the service to "allow interact with desktop" as the service cant use Local System account but rather has to use credentials of specific user.
I wasn't sure if it is intended to work like that, but I also tried to connect to that windbg in session 0 from another instance of Windbg using Windbg -pe (so I would have two Windbg running). But it doesn't work - the second instance doesn't seem to be able to stop the process and see its call stack.
Any ideas how to attach a debugger to the child process before it crashes to debug it?
You can use the command line debugger cdb for that.
Start your service with cdb attached, and launched as a debugging server.
You can add the following command
"c:\program files\debugging tools for windows\cdb" -server
tcp:port=5500 -g -G
to the registry value Debugger (type string) of the registry key
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution
Options\YourApplication.Exe
Then use windbg to connect to the debugging server with
windbg -remote tcp:server=localhost,port=5500
One more option:
When WinDbg is automatically launched, you indeed can't see it. You can, however, configure ntsd as your jit debugger, and enable remote debugging. Then, you can connect your WinDbg to ntsd and remote debug the process. See for details: Debugging a Service on Windows Vista.
Why not start from crash dumps? http://www.codeproject.com/KB/debug/automemorydump.aspx
Add Sleep(30000) to your child process entry point. That will give you enough time to connect with the debugger.
I set up my development environment on a widows server 2008 r2 machine. The problem is that whenever a process that is running in session 0 crashes, i get absolutely no notification of it. No Windows error reporting, no visual studio jit debugging prompt. If a regular application crashes, then i get the jit debugging popup and am able to attach the debugger fine. What could be going on?
In W2K8 session 0 services run with no UI (non interactive). Therefore you'll never get a popup. One way around this is to set your AEDebug regkey to attach either ntsd or cdb with remote debugging, something like ntsd.exe -server tcp:port=50000:54999 -p %ld -e %ld -g -noio. Then when something crashes, you will see the ntsd.exe process running in taskmgr and you can attach to it (you'll need to use cdb and query which ports are open for debugging). This can easily be wrapped in some sort of daemon process or service that's continuously monitoring for new debugging sessions and automatically pop up cdb for you.
You can then extend this pattern to launch an arbitrary logging process instead of ntsd. Just make sure the process is running with the right permissions and no UI.
I have a console application (written in VB6 ) which is behaving strangely on my machine. I kick it off from the command line and what should be a two minute job drops straight back to the prompt - if I run this on another machine the executable will sit and wait until the job finishes before returning control back to the prompt. If I check process explorer I can see that the executable is running as a background process and other than this strange background-ness is running as expected.
Any thoughts on why this could be happening? (Running on 32-bit Windows XP Pro SP3.)
It's totally unclear whether this is an application you wrote and have the source code for. If that's the case, you need to get in and start debugging. At the least, use OutputDebugString to send information about what's going on to any number of potential viewers. Taking that a step further, consider rewiring the app using the Console module I wrote, along with vbAdvance to recompile. This combination will allow you the full power of the VB6 IDE to debug within. No more guessing about what's going on.
Then again, if it's not your app, I'm not sure what VB6 has to do with it and wish you the best of luck trying to figure out what's up.
It sounds to me as though the app isn't being recognised as a console app on one of your machines. Console apps weren't officially supported in VB6, although there are some well-known hacks for creating them (particularly the free add-in vbAdvance). Possibly your console app is a bit unreliable? If Windows thinks your app is a GUI rather than a console app, it won't wait for it to finish.
As a pragmatic workaround: try launching with start /wait rather than just using the exename. That forces the command prompt to wait for the program to finish, whether it's a GUI app or a console app.
Sounds like an error is occurring that is being 'swallowed' by the application. Do you have the source code?
Errors in VB6 apps are often due to some COM component not installed and/or registered.
Download SysInternals Process Monitor and this will show up accesses to ProgIDs that fail (uninstalled/unregistered COM components).
Check out: Process Monitor - Hands-On Labs and Examples.
Have you checked permissions? Is the application accessing any network based resources?
I am developing a Browser Helper Object running inside Internet Explorer. I am writing debugging messages with ATLTRACE("..."); These appear fine when Visual Studio is attached to the iexplore.exe process, but this is slow for a quick test. DebugView captures nothing from my BHO.
Why does DebugView not show BHO debug messages? Is it something to do with Internet Explorer running at low integrity level?
Assuming that you're running IE on Vista or later (which it sounds like since you're talking about integrity levels), you can set the integrity level of DebugView to a lower integrity so any application can send messages to it:
icacls dbgview.exe /setintegritylevel low
And if you don't like the idea of permanently setting dbgview to low integrity (it might make saving logs and whatnot a bit of a pain, as they will only go into the low-integrity store) you can run a particular instance of dbgview at low integrity using Sysinternals' psexec tool:
psexec -l dbgview
Finally, if all you're worried about is the amount of time that it takes to load up the VS debugger to attach to the process, you can use a command line debugger (like ntsd.exe or cdb.exe). Ntsd.exe comes with Windows, but a newer version comes with the "Debugging Tools for Windows" package, which also includes the very similar cdb.exe.
For your quick tests, is Visual Studio still running? If so, that might cause this problem.
I am working on an ASP.NET web application, it seems to be working properly when I try to debug it in Visual Studio. However when I emulate heavy load, IIS crashes without any trace -- log entry in the system journal is very generic, "The World Wide Web Publishing service terminated unexpectedly. It has done this 4 time(s)."
How is it possible to get more information from IIS to troubleshoot this problem?
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/ms954594.aspx
Crash dump of asp.net process should give you tons of info..If you want to quickly get some info on why the process got recycled, try this tip from Scott Gu..
Health monitoring feature of asp.net 2.0 is also worth looking at..
The key is "without any trace". You need to put your own trace logging in to create some chatter. Then you'll be able to spot where the chatter stops.