dia_rich
asked on
XP Application Error 1000
Have an application (vs2005 mfc release build) which dies once a day about the
same time with the same event (1000) and ref address 0x0000daa7.
I am trying to find out where in my application the thing is dying.
Does this work?
Take the link map for the build,
find the module address within the link map which has contains the
error event reference address, then subtract that modules starting address
from the reference address find that offset in the assembly & source listings for the
module and you are there (or close at least).
same time with the same event (1000) and ref address 0x0000daa7.
I am trying to find out where in my application the thing is dying.
Does this work?
Take the link map for the build,
find the module address within the link map which has contains the
error event reference address, then subtract that modules starting address
from the reference address find that offset in the assembly & source listings for the
module and you are there (or close at least).
ASKER
No not running debug build. See orginal question (release build) Yes I would love to run the debug build but the target computer doesen't have development environment on it.
As far as the application error dialog looks like this.
201104Apr24-3EAppHCrash.pdf
As far as the application error dialog looks like this.
201104Apr24-3EAppHCrash.pdf
ASKER
The question was basically a "gravity check" to use someone else's eyes on what I was doing to
determine which line in the code the application is failing at.
That article seems to describe what I am doing.
Only if you get the output of the complier to create a list file which showes the assembly with
memory offset & the source embedded in it.
There seems to be a way to get a dump/minidump file for the crash, and then open it with visual studio. . . . Unix is soooo much better for issues like ths.
determine which line in the code the application is failing at.
That article seems to describe what I am doing.
Only if you get the output of the complier to create a list file which showes the assembly with
memory offset & the source embedded in it.
There seems to be a way to get a dump/minidump file for the crash, and then open it with visual studio. . . . Unix is soooo much better for issues like ths.
You can debug the program by doing the following steps.
1. Include the debug information in release build. Go to the menu Project Properties->configuration properties->General --> Debug information row on the right side --> select Program Database.
2. Disable optimization - same project property page but select optimization and select disabled from the drop down.
3. Under Linker->debugging --> enable Generate Debug Info by selecting Yes(DEBUG) from the drop down
4. Compile the source and copy the binary to the target machine.
5. Download and Install WinDbg (Microsoft Application) (http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.11.1.404.msi)
6. Launch the WinDbg.exe from the installed folder with -I or -IS command line parameter. (S for silent). Press OK (if -S is not included). This makes the WinDbg as postmortem deubgger.
7. Goto registry entry. HKEY_LOCAL_MACHINE->SOFTWA
8. In the Value data field, type -c “.dump /mf /u C:\Dump.dmp” between {-p %ld} and {-e %ld......}
9. Let the application run on the target machine. Once it dies, the crash dump will be created by WinDbg on C drive. Copy the dump to your machine and open it with WinDbg.
10. Enter the source files location and symbol files location from the file menu of WinDbg. (dont delete the files after compilation done earlier)
The WinDbg shows the exact the line at which your code is crashed.
If you are still not able to find out, the only other possible way is, you need to find out all the win32 api calls. If any parameter is wrong, (e.g. fopen(filename, "RRRR"), mode is wrong). In this case, the API try to invoke invalid parameter handler which inturn closes (terminates) your application. No debugger can catch this exactly.
Hope this helps.
1. Include the debug information in release build. Go to the menu Project Properties->configuration properties->General --> Debug information row on the right side --> select Program Database.
2. Disable optimization - same project property page but select optimization and select disabled from the drop down.
3. Under Linker->debugging --> enable Generate Debug Info by selecting Yes(DEBUG) from the drop down
4. Compile the source and copy the binary to the target machine.
5. Download and Install WinDbg (Microsoft Application) (http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.11.1.404.msi)
6. Launch the WinDbg.exe from the installed folder with -I or -IS command line parameter. (S for silent). Press OK (if -S is not included). This makes the WinDbg as postmortem deubgger.
7. Goto registry entry. HKEY_LOCAL_MACHINE->SOFTWA
8. In the Value data field, type -c “.dump /mf /u C:\Dump.dmp” between {-p %ld} and {-e %ld......}
9. Let the application run on the target machine. Once it dies, the crash dump will be created by WinDbg on C drive. Copy the dump to your machine and open it with WinDbg.
10. Enter the source files location and symbol files location from the file menu of WinDbg. (dont delete the files after compilation done earlier)
The WinDbg shows the exact the line at which your code is crashed.
If you are still not able to find out, the only other possible way is, you need to find out all the win32 api calls. If any parameter is wrong, (e.g. fopen(filename, "RRRR"), mode is wrong). In this case, the API try to invoke invalid parameter handler which inturn closes (terminates) your application. No debugger can catch this exactly.
Hope this helps.
ASKER
rushtoshankar:
Comment & question.
I was missing the generate debug info for release build.
Are you saying that I need to install & setup the WinDbg on the target machine?
Can't I just use the minidump that is created when the "the app has died. do you wanna send info to microsoft?".
Comment & question.
I was missing the generate debug info for release build.
Are you saying that I need to install & setup the WinDbg on the target machine?
Can't I just use the minidump that is created when the "the app has died. do you wanna send info to microsoft?".
"I was missing the generate debug info for release build. "
--> check the menu Project -> Properties --> Configuration Properties --> Linker --> Debugging and on the right side, first row show Generate debug info. Enable this for release build.
If you still not able to see, please let me know the version of visual studio that you are using. I am using Visual Studio 2005 Pro edition (Version 8.0.50727.867)
"Are you saying that I need to install & setup the WinDbg on the target machine?"
Yes. You need to install the windbg to create the dump. You need WinDbg in you development machine to analzye the dump.
"Can't I just use the minidump that is created when the "the app has died. do you wanna send info to microsoft?". This will not have sufficient information. If you use the dump created by WinDbg, with proper source and symbols, it will pin point you the exact line from your code. You can debug the code just like you stopped with a break point. (all registers, stack info, global variables etc..)
--> check the menu Project -> Properties --> Configuration Properties --> Linker --> Debugging and on the right side, first row show Generate debug info. Enable this for release build.
If you still not able to see, please let me know the version of visual studio that you are using. I am using Visual Studio 2005 Pro edition (Version 8.0.50727.867)
"Are you saying that I need to install & setup the WinDbg on the target machine?"
Yes. You need to install the windbg to create the dump. You need WinDbg in you development machine to analzye the dump.
"Can't I just use the minidump that is created when the "the app has died. do you wanna send info to microsoft?". This will not have sufficient information. If you use the dump created by WinDbg, with proper source and symbols, it will pin point you the exact line from your code. You can debug the code just like you stopped with a break point. (all registers, stack info, global variables etc..)
ASKER
Ok recreated a release build with the debug stuff turned on (already had the linker debug property set.
Installed the win debug on the target system.
Ran with -I to make it the default debuger.
Changed the registry.
Started the app and waited for it to die, which it did and the debuger started up.
I clicked the save to workspace and it created a 25Mbyte .dmp file.
Xfered the dump back to the development machine.
Started windebg and set the symbol path to the directory where the release .pdb file is.
Set the image path to where the release .exe file is.
Set the source path to where the source code is.
Opened the dump file and got this:
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [H:\Documents and Settings\Rich\My Documents\Visual Studio 2005\Projects\My Projects\Test03i\Release\T
User Mini Dump File with Full Memory: Only application data is available
WARNING: Path element is empty
Symbol search path is: H:\WINDOWS\SYMBOLS;;H:\Doc
Executable search path is: H:\Documents and Settings\Rich\My Documents\Visual Studio 2005\Projects\My Projects\Test03i\Release
Windows XP Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Fri Oct 21 14:13:52.000 2011 (GMT-4)
System Uptime: 7 days 2:52:48.388
Process Uptime: 0 days 11:03:58.000
..........................
eax=7ffde000 ebx=00000001 ecx=00000002 edx=00000003 esi=00000004 edi=00000005
eip=7c96149b esp=0182ffc8 ebp=0182fff4 iopl=0 nv up ei ng nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010286
ntdll!RtlExitUserThread:
7c96149b 8bff mov edi,edi
0:000> !analize -v
No export analize found
Not real helpful.
Installed the win debug on the target system.
Ran with -I to make it the default debuger.
Changed the registry.
Started the app and waited for it to die, which it did and the debuger started up.
I clicked the save to workspace and it created a 25Mbyte .dmp file.
Xfered the dump back to the development machine.
Started windebg and set the symbol path to the directory where the release .pdb file is.
Set the image path to where the release .exe file is.
Set the source path to where the source code is.
Opened the dump file and got this:
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [H:\Documents and Settings\Rich\My Documents\Visual Studio 2005\Projects\My Projects\Test03i\Release\T
User Mini Dump File with Full Memory: Only application data is available
WARNING: Path element is empty
Symbol search path is: H:\WINDOWS\SYMBOLS;;H:\Doc
Executable search path is: H:\Documents and Settings\Rich\My Documents\Visual Studio 2005\Projects\My Projects\Test03i\Release
Windows XP Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Fri Oct 21 14:13:52.000 2011 (GMT-4)
System Uptime: 7 days 2:52:48.388
Process Uptime: 0 days 11:03:58.000
..........................
eax=7ffde000 ebx=00000001 ecx=00000002 edx=00000003 esi=00000004 edi=00000005
eip=7c96149b esp=0182ffc8 ebp=0182fff4 iopl=0 nv up ei ng nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010286
ntdll!RtlExitUserThread:
7c96149b 8bff mov edi,edi
0:000> !analize -v
No export analize found
Not real helpful.
analyze -v didnt tell you anything? (not analize)
ASKER
Yea, caught that fat finger. . .
Here is the actual . . .analyze
0:000> !analyze -v
**************************
* *
* Exception Analysis *
* *
**************************
**************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
**************************
**************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
**************************
FAULTING_IP:
+2bb952f01f3df74
00000000 ?? ???
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0
FAULTING_THREAD: 000016c8
DEFAULT_BUCKET_ID: STACKIMMUNE
PROCESS_NAME: 3ETest03_10_21.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS
ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [Is_ChosenCrashFollowupThr
LAST_CONTROL_TRANSFER: from 7c95002e to 7c96149b
PRIMARY_PROBLEM_CLASS: STACKIMMUNE
BUGCHECK_STR: APPLICATION_FAULT_STACKIMM
STACK_TEXT:
00000000 3ETest03_10_21+0x0
SYMBOL_NAME: 3ETest03_10_21
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: 3ETest03_10_21
IMAGE_NAME: 3ETest03_10_21.exe
DEBUG_FLR_IMAGE_TIMESTAMP:
STACK_COMMAND: ** Pseudo Context ** ; kb
FAILURE_BUCKET_ID: STACKIMMUNE_80000003_3ETes
BUCKET_ID: APPLICATION_FAULT_STACKIMM
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/3ETest03_10_21_exe/1_0_0_1/4ea086b1/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1
Followup: MachineOwner
---------
As I said in my first comment, it was just killed by Microsoft API for the invalid argument.
(e.g. fopen(filename, "RRRR"). filename -> path to a file that is present in the disk. In this case, you should get an error saying RRRR is an invalid parameter. But the invalid argument handler kills the application.
The only way to find this out is based on debug messages, you should look for a windows API with invalid parameter passed.
I faced the problem with the following code.
COleDateTime oleData = tTimet (tTime is of 64 bit time_t type with value greater than _MAX__TIME64_T).
But it is within the range that time_t but beyond _MAX__TIME64_T.
During the conversion, the MS api found that this is invalid parameter with higher value. It invoked invalid parameter handler which in turn calls TerminateApplication.
This thread might be appropriate for your situation.
http://msdn.microsoft.com/en-us/library/ksazx244.aspx
(e.g. fopen(filename, "RRRR"). filename -> path to a file that is present in the disk. In this case, you should get an error saying RRRR is an invalid parameter. But the invalid argument handler kills the application.
The only way to find this out is based on debug messages, you should look for a windows API with invalid parameter passed.
I faced the problem with the following code.
COleDateTime oleData = tTimet (tTime is of 64 bit time_t type with value greater than _MAX__TIME64_T).
But it is within the range that time_t but beyond _MAX__TIME64_T.
During the conversion, the MS api found that this is invalid parameter with higher value. It invoked invalid parameter handler which in turn calls TerminateApplication.
This thread might be appropriate for your situation.
http://msdn.microsoft.com/en-us/library/ksazx244.aspx
Try setting the handler to your function and check if you get the control during crash/close
ASKER
So somehow it knows that an invalid argument was passed . . .but won't tell what call it was that had the issue. . .
What a feature. . .
When you say set the handler to "your function" do you mean an existing function of the app or one created to handle this?
What a feature. . .
When you say set the handler to "your function" do you mean an existing function of the app or one created to handle this?
No debugger can found this crash/kill.
Look at the function _set_invalid_parameter_han
You need to writea simple funciton with the prototype required for this function and pass your function's pointer to this function. Whenever you encounter the invalid parameter error, your function will be called by Microsoft CRT functions. Inside your function you can print the values provided by CRT libraries.
add this function to your code.
void invalid_parameter_my_handl
const wchar_t * expression,
const wchar_t * function,
const wchar_t * file,
unsigned int line,
uintptr_t pReserved
)
{
print all the input parameters here.
}
add the following line to your starup sequence
_set_invalid_parameter_han
during the error scenario, your function will get executed, you can find the details of the invalid function.
Look at the function _set_invalid_parameter_han
You need to writea simple funciton with the prototype required for this function and pass your function's pointer to this function. Whenever you encounter the invalid parameter error, your function will be called by Microsoft CRT functions. Inside your function you can print the values provided by CRT libraries.
add this function to your code.
void invalid_parameter_my_handl
const wchar_t * expression,
const wchar_t * function,
const wchar_t * file,
unsigned int line,
uintptr_t pReserved
)
{
print all the input parameters here.
}
add the following line to your starup sequence
_set_invalid_parameter_han
during the error scenario, your function will get executed, you can find the details of the invalid function.
ASKER
Yea, Ilooked at the link and it detailed how to have the system tell you that you passed an invalid parameter to printf and how to show you where in printf it found the issue.
Great.
I need to know where in my app I am passing the invalid parameter (once a day).
Seeing the call stack would do the trick.
If you ever get to analize a core dump in unix you will understand my frustration with mfc.
Great.
I need to know where in my app I am passing the invalid parameter (once a day).
Seeing the call stack would do the trick.
If you ever get to analize a core dump in unix you will understand my frustration with mfc.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
No help at getting to the cause of my issue.
Are you running debug build?
It would beneficial running debug build; you should be able to stop debugging and walk the stack to get to the source of a problem.