Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 788
  • Last Modified:

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).
0
dia_rich
Asked:
dia_rich
  • 8
  • 7
  • 2
1 Solution
 
Janusz CzopowikCommented:
You are getting more information than you revealed. Post entire log error.
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.
0
 
dia_richAuthor Commented:
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
0
 
Janusz CzopowikCommented:
Sorry, missed release build.
Another option would be to set remote debugging.

Also, look here
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
dia_richAuthor Commented:
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.
0
 
rushtoshankarCommented:
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->SOFTWARE->Microsoft->Windows NT->CurrentVersion->AeDebug
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.
0
 
dia_richAuthor Commented:
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?".
0
 
rushtoshankarCommented:
"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..)
0
 
dia_richAuthor Commented:
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\Test03_10a8_2011-10-21_12-13-52-143_0bf0.dmp]
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:\Documents and Settings\Rich\My Documents\Visual Studio 2005\Projects\My Projects\Test03i\Release
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.

0
 
rushtoshankarCommented:
analyze -v didnt tell you anything?  (not analize)
0
 
dia_richAuthor Commented:

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:  0

ADDITIONAL_DEBUG_TEXT:  Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[ffffffff]

LAST_CONTROL_TRANSFER:  from 7c95002e to 7c96149b

PRIMARY_PROBLEM_CLASS:  STACKIMMUNE

BUGCHECK_STR:  APPLICATION_FAULT_STACKIMMUNE

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:  4ea086b1

STACK_COMMAND:  ** Pseudo Context ** ; kb

FAILURE_BUCKET_ID:  STACKIMMUNE_80000003_3ETest03_10_21.exe!Unknown

BUCKET_ID:  APPLICATION_FAULT_STACKIMMUNE_3ETest03_10_21

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
---------
0
 
rushtoshankarCommented:
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
0
 
rushtoshankarCommented:
Try setting the handler to your function and check if you get the control during crash/close
0
 
dia_richAuthor Commented:
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?
0
 
rushtoshankarCommented:
No debugger can found this crash/kill.
Look at the function _set_invalid_parameter_handler (mentioned in the link).
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_handler(
   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_handler(invalid_parameter_my_handler);

during the error scenario, your function will get executed, you can find the details of the invalid function.
0
 
dia_richAuthor Commented:
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.
0
 
rushtoshankarCommented:
I have done that in Linux/Unix. But quite some time back. Thats why I gave you the longest, only way of finding this crash dump, because this is a special case and this is the only possible way to narrow down. Hope you can find your problematic parameter.
Don't know which version of CRT function will have the fix. Even i don't know if this is the expected behavior.
0
 
dia_richAuthor Commented:
No help at getting to the cause of my issue.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 8
  • 7
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now