Re: debugging/ NTDLL.DLL/ and more

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Reordered for better debugging

>> ntdll.dll!_RtlpCoalesceFreeBlocks@16() + 0x124e bytes
>> ntdll.dll!_RtlpExtendHeap@8() + 0xa1 bytes
>> ntdll.dll!_RtlAllocateHeap@12() + 0x16a2 bytes
>> prophecy city.exe!malloc(unsigned int size=196608) Line 163 + 0x63
>> bytes C
>>> prophecy city.exe!LoadBitmapFile(char * filename=0x00000024,
>>> tagBITMAPINFOHEADER * _bitmapInfoHeader=0x00364d42) Line 3498 + 0x9
>>> bytes C++

Here filename is not a valid pointer, however the failure indicates that
fopen succeeded, therefore it seems the arguments area of your stack has
been overwritten.... this will lead to failures accessing _bitmapInfoHeader

I don't see anything wrong with the code after a cursory inspection, so you
will be debugging...

>> ------------
>>
>> THIS IS THE FUCTION:
>> unsigned char *LoadBitmapFile(char *filename, BITMAPINFOHEADER
>> *_bitmapInfoHeader)

Use this prototype instead (safer!)
unsigned char *LoadBitmapFile(const char* const filename, BITMAPINFOHEADER*
const _bitmapInfoHeader)
>>
>> {

Put a breakpoint [here]!

Check your arguments. Add the following code (use your favorite
logging/reporting mechanism in place of MessageBox):

if ((NULL == filename) || IsBadStringPtr(filename, _MAX_PATH)) {
MessageBox(...);
}
if ((NULL == _bitmapInfoHeader) || IsBadWritePtr(_bitmapInfoHeader, sizeof
*_bitmapInfoHeader)) {
MessageBox(...);
}

Then recompile and launch in debug mode. When the debugger breaks, visually
inspect the arguments (make sure the filename is reasonable, etc.).

Now added both arguments to the watch list and begin stepping through the
function (use step over).

Find out what line causes filename to get corrupted. Watch to see if
_bitmapInfoHeader also changes.


>>
>> FILE *filePtr; // the file pointer
>>
>> BITMAPFILEHEADER bitmapFileHeader; // bitmap file header
>>
>> unsigned char *bitmapImage; // bitmap image data
>>
>> int imageIdx = 0; // image index counter
>>
>> unsigned char tempRGB; // swap variable
>>
>> // open filename in "read binary" mode
>>
>> filePtr = fopen(filename, "rb");
>>
>> if (filePtr == NULL)
>>
>> return NULL;

tested return value.... check

>>
>> // read the bitmap file header
>>
>> fread(&bitmapFileHeader, sizeof(BITMAPFILEHEADER), 1, filePtr);

Check return value!

>>
>>
>> // verify that this is a bitmap by checking for the universal bitmap id
>>
>> if (bitmapFileHeader.bfType != BITMAP_ID)
>>
>> {
>>


tested value.... check

>> fclose(filePtr);
>>
>> return NULL;
>>
>> }
>>
>> // read the bitmap information header
>>
>> fread(_bitmapInfoHeader, sizeof(BITMAPINFOHEADER), 1, filePtr);
>>

Check return value!

>> // move file pointer to beginning of bitmap data
>>
>> fseek(filePtr, bitmapFileHeader.bfOffBits, SEEK_SET);
>>

Check return value!

>> // allocate enough memory for the bitmap image data
>>
>> THIS IS WHERE THE ERROR OCCURS:
>>
>> bitmapImage = (unsigned char*)malloc(_bitmapInfoHeader->biSizeImage);
>>

If any of the above reads fail then _bitmapInfoHeader->biSizeImage is
meaningless.


.

Relevant Pages

  • Shapes.AddPicture(...) new images are ignored
    ... during debugging. ... int height = image.Height; ... already been removed fromthe file system. ... DateTime.Now.toStringonto the filenames to at least have a new filename on ...
    (microsoft.public.powerpoint)
  • RE: Checking to see if file exists.
    ... debugging. ... my problem was with the "if (-e $filename)" always returning ... "Perl is the duct tape of the Internet." ...
    (perl.beginners)
  • Re: netbeans debugger and local variables
    ... After trying and retrying, ... So now Im trying to record the state of the debugging options... ... Doesn't it's value show up in a tooltip? ...
    (comp.lang.java.softwaretools)
  • Re: netbeans debugger and local variables
    ... After trying and retrying, ... So now Im trying to record the state of the debugging options... ... Doesn't it's value show up in a tooltip? ...
    (comp.lang.java.programmer)
  • Re: An obscure bug in DIRECTORY
    ... We have OpenVMS 7.3-1 and the same failure. ... The error occurs if you omit ... the filename, -type and -version. ...
    (comp.os.vms)