I'm writing a Windows C++ program in Visual Studio 2010 and have heap corruption. The !heap and !avrf debugger extensions from Application Verifier have several tools that sound quite useful for tracking this down, however I am unclear as to how to effectively use Application Verifier. For instance, Application Verifier documentation states:
You can use !avrf -hp -a Address to display all heap space operations that affected the specified Address.
Where exactly does one type this command? (Yes, I know Address needs to be replaced by an actual address.) Does it need to be prefixed by anything?
It's a Windows debugger command. You can see the help for the command here.
Related
I have an application, that I want to profile using Windows Performance Analyzer. It all works, but I don't get any reasonable stack traces from my application.
The application in question is a demo application. This is to give me a good feeling if all checks out. Then I want to profile another application. Since I have full control over my demo application, I included some marker functions, that should show up in the stack trace.
When running the application on Windwos 71, Process Explorer shows the correct stack trace for the part, that I want to profile. Here is the stack trace with the marker functions in lines 7 - 9:
Since I installed all performance analytics tools insinde a Windows 10 VM2, I started profiling there. The first thing to notice: Process Explorer does not show the correct stack trace. The marker functions that I implemented are nowhere to be found.
Nevertheless, I recorded performance traces using UIforETW and Windows Performance Recorder. When opening them in WPA and focussing on the target application, this is the stack trace:
All the information, I'm interested in is missing. The stack shows up as <Application>.exe!<Missing ImageId event>
What did I do wrong?
If this gives you a hint, here is the relevant software, that is installed:
1: The Windows 7 computer has Visual Studio (C#) installed.
2: The Windows 10 VM dowsn't have Visual Studio, but has WinDBG (Preview) and Windows Performance Toolkit installed.
I tagged delphi, because the target application is written in Delphi.
The Windows 10 WPA (as well as Windows 8.1, to a lesser extent) dropped support for older debug symbol formats; it now only supports the "RSDS" format that has been standard since MSVC 7. PE files using older symbol file formats (for example, VB6 generates NB10 PDB files) will result in that "Missing ImageId event" error.
(The message itself is technically incorrect; there likely is an ImageId even in the trace file but it is looking for an ImageId/DbgID_RSDS event, which can't be generated for non-RSDS PDBs)
<Missing ImageId event> will also be reported when the session is not merged with the "NT Kernel Logger" which provides some information necessary to resolve the symbols.
The "proper" way to stop the session is:
xperf.exe -stop my_trace -stop -d merged_trace.etl
Note that second -stop in necessary to stop another session (implicitly "NT Kernel Logger"), and -d to merge both into the merged_trace.etl.
i coded a big project in c++ that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs after 5 seconds. It just doesn't reply anymore and is tagged as inactive in taskmanager. I tried to analyse the error with the windows debugger tools and application verfier, but i found nothing. Even when I set the "_NO_DEBUG_HEAP=1", the error doesn't occur, it just happens when I start it with ctrl + f5 or outside from visual studio. I'm not even sure if the _NO_DEBUG_HEAP works... Anyone have an idea what could be wrong ?
Any number of things may cause this.
Based on my passed experience, I suggest tackling this by removing code until the behaviour disappears... then determining why removing the code in question corrected the behaviour. (the removed code may not have been the cause, only a catalyst for the symptom)
If I was tasked with taking a quick glance to spot the error, I would think to look for buffer overrun related issues. This type of error has more safeguards in debug than executing a final build. That's just a stab in the dark based on buffer overruns being a common issue that kinda fits the symptom.
-dm
Common things to check:
Are you sure your application is setting any memory used to zero,
if it is assuming the memory has to be zeroed out?
Visual Studio might be initializing the memory given to the
application.
Is all the memory allocated being deallocated?
There are no un-initialized pointers being used?
There are no un-initialized variables being used?
64 bit exe crashing outside visual studio but working inside visual studio
Does the problem only happen on one computer?
You can use check_heap to check the validity of the heap
in the program:
Program crashes only in Release mode outside debugger
You can use the Windows debugging tools to show heap
corruption - there is a tool called "gflags" that comes with the
Microsoft "Standalone Debugging Tools for Windows"
https://msdn.microsoft.com/en-us/windows/hardware/hh852365
This URL shows how to run gflags against your .EXE:
Visual Studio - how to find source of heap corruption errors
I have a completely random error popping up on a particular piece of software out in the field. The application is a game written in VB6 and is running on Windows 7 64-bit. Every once in a while, the app crashes, with a generic "program.exe has stopped responding" message box. This game can run fine for days on end until this message appears, or within a matter of hours. No exception is being thrown.
We run this app in Windows 2000 compatibility mode (this was its original OS), with visual themes disabled, and as an administrator. The app itself is purposely simple in terms of using external components and API calls.
References:
Visual Basic for Applications
Visual Basic runtime objects and procedures
Visual Basic objects and procedures
OLE Automation
Microsoft DAO 3.51 Object Library
Microsoft Data Formatting Object Library
Components:
Microsoft Comm Control 6.0
Microsoft Windows Common Controls 6.0 (SP6)
Resizer XT
As you can see, these are pretty straightforward, Microsoft-standard tools, for the most part. The database components exist to interact with an Access database used for bookkeeping, and the Resizer XT was inserted to move this game more easily from its original 800x600 resolution to 1920x1080.
There is no networking enabled on the kiosks; no network drivers, and hence no connections to remote databases. Everything is encapsulated in a single box.
In the Windows Application event log, when this happens, there is an Event ID 1000 faulting a seemingly random module -- so far, either ntdll.dll or lpk.dll. In terms of API calls, I don't see any from ntdll.dll. We are using kernel32, user32, and winmm, for various file system and sound functions. I can't reproduce as it is completely random, so I don't even know where to start troubleshooting. Any ideas?
EDIT: A little more info. I've tried several different versions of Dependency Walker, at the suggestion of some other developers, and the latest version shows that I am missing IESHIMS.dll and GRPSVC.dll (these two seems to be well-known bugs in Depends.exe), and that I have missing symbols in COMCTRL32.dll and IEFRAME.dll. Any clues there?
The message from the application event log isn't that useful - what you need is a post mortem process dump from your process - so you can see where in your code things started going wrong.
Every time I've seen one of these problems it generally comes down to a bad API parameter rather than something more exotic, this may be caused by bad data coming in, but usually it's a good ol fashioned bug that causes the problem.
As you've probably figured already this isn't going to be easy to debug; ideally you'd have a repeatable failure case to debug, instead of relying on capturing dump files from a remote machine, but until you can make it repeatable remote dumps are the only way forwards.
Dr Watson used to do this, but is no longer shipped, so the alternatives are:
How to use the Userdump.exe tool to create a dump file
Sysinternals ProcDump
Collecting User-Mode dumps
What you need to get is a minidump, these contain the important parts of the process space, excluding standard modules (e.g. Kernel32.dll) - and replacing the dump with a version number.
There are instructions for Automatically Capturing a Dump When a Process Crashes - which uses cdb.exe shipped with the debugging tools, however the crucial item is the registry key \\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
You can change your code to add better error handling - especially useful if you can narrow down the cause to a few procedures and use the techniques described in Using symbolic debug information to locate a program crash. to directly process the map files.
Once you've got a minidump and the symbol files WinDbg is the tool of choice for digging into these dumps - however it can be a bit of a voyage to discover what the cause is.
The only other thing I'd consider, and this depends on your application structure, is to attempt to capture all input events for replay.
Another option is to find a copy of VMWare 7.1 which has replay debugging and use that as the first step in capturing a reproducible set of steps.
Right click your executable object and let it be WINXP compatible pending
when you discover source of the problem to finally solve it
I wrote some program which uses information about (reads via Windows) hardware of the current PC (big program, so I can't post here code) and sometimes my windows 7 crashes, the worst thing is that I have no idea why, and debug doesn't help me, is there any way to receive from windows 7 some kind of log, why it crashed? thanks in advance for any help
The correct (but somewhat ugly) answer:
Go to Computer->Properties, go to 'Advanced System Settings'.
Under startup and recovery, make sure it is set to "Kernel memory dump" and note the location of the dump file (on a completely default install, you are looking at C:\windows\memory.dmp)
You optimally want to install Windows Debugging tools (now in the Windows SDK) as well as setting the MS Symbol store in your symbol settings (http://msdn.microsoft.com/en-us/library/ff552208(v=vs.85).aspx)
Once youv'e done all that, wait for a crash and inspect memory.dmp in the debugger. Usually you will not see the exact crash because your driver vendors don't include symbols, but you will also generally get to see the DLL name that is involved in the crash, which should point you to what driver you are dealing with.
If you are not seeing a specific driver DLL name in the stack, it often indicates to me a hardware failure (like memory or overhead) that needs to be addressed.
MS has a good article here at technet that describes what I mentioned above (but step by step and in greater detail) http://blogs.technet.com/b/askcore/archive/2008/11/01/how-to-debug-kernel-mode-blue-screen-crashes-for-beginners.aspx
You can also look at the event log as someone else noted, but generally the information there is next to useless, beyond the actual kernel message (which can sometimes vaguely indicate whether the problem is driver or something else)
I'm debugging an intermittent problem in which an application (created using C++ in Visual Studio 2005) is faulting. The event log provides the following information:
faulting module msvcr80.dll
version 8.0.50727.1433
fault address 0x00008aa0
I did a Google search and found many other examples of applications crashing with this particular fault address, but no indication of what it means.
Is there any way to find out what msvcr80.dll is doing at this address?
I tried attaching to a running instance of the application from Visual Studio to see what code is located at 0x00008aa0 -- but there doesn't seem to be anything there!
More generally, given an address somewhere in a Windows DLL, is there a way to figure out what the code is doing?
Windows will never map anything to addresses lower than 0x10000, so you are definitely AV'ing.
Googling myself, someone suggested using dependency walker to find out which module you're using that is directly dependent on msvcr80.dll -- since you are using VS 2005.
That might give you a clue where to start isolating the bug.
Address this low usually indicates a null pointer access violation. The offset of the member access accessed to the base pointer is 8aa0. Looks like a pretty large object. I would suggest you add null-asserts when you dereference pointers to objects of large data type.
You can try to use Microsoft debug symbols, in this case you will see normal function name instead of address.
In VS2005 you should do:
Go to Tools -> Options -> Debugging -> Symbols
Insert http://msdl.microsoft.com/download/symbols as a symbol location
Attach VS to your app instance and repeat the crash