Re: PB 4.2 - why does the COREDLL!FillInOneHeap(THSNAP ...) cause Debug Break ?
From: sergeir (anonymous_at_discussions.microsoft.com)
Date: 03/01/05
- Next message: Tweeeek: "Re: SANDISK Compact FLash"
- Previous message: rcxkid: "Re: BLDR crashing in decoder??"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 1 Mar 2005 06:54:06 -0800
Hi Sue and thanks for the reply,
I see that DEBUGCHK() detects something bad. In my code
this is the first function call in another function(see
below). Can't find any corruption here or buffer overflow.
Maybe it needs some prefixing with something or some
system call before ?
Best regards
Sergei
>-----Original Message-----
>It looks like FillInOneHeap will DEBUGCHK() if it detects
heap corruption.
> Is it possible there's a buffer overflow in your code?
Are you able to
>use the debugger to find the address FillInOneHeap was
examining? That might
>help you figure out what the buffer was.
>
>You can probably get past the debugchk by using the
SNAPNOHEAPS flag, but
>really I'd recommend you find the corrupted memory and
fix that problem before
>turning off the heap-snap.
>
>Hope that helps,
>
>Sue
>sloh@microsoft.com (remove "online" from reply-to
address)
>http://blogs.msdn.com/sloh/
>__________________________________________________________
___
>This posting is provided "AS IS" with no warranties, and
confers no rights.
>__________________________________________________________
___
>
>Have an opinion on the effectiveness of Microsoft
Embedded newsgroups? Let
>us know!
>https://www.windowsembeddedeval.com/community/newsgroups
>
>
>> Hi experts,
>>
>> while using the Platfrom Builder 4.2 we need to find
out whether a
>> process is already running ( our shell is supposed to
autostart it on
>> boot). To do so a snapshot of all processes in Windows
CE device is
>> obtained and searched for the interested one.
>>
>> It works but each such call to TOOLHELP!
CreateToolhelp32Snapshot()
>> casues debugBreak. The call stack shows the following
>>
>> COREDLL!DebugBreak() line 102
>> COREDLL!FillInOneHeap(THSNAP * 0x12160000, heap *
>> 0x06030000, TH32HEAPENTRY * * 0x12167e04, unsigned long
>> 3279630994) line 1855
>> COREDLL!GetHeapSnapshot(THSNAP * 0x12160000, int 1,
void *
>> * 0x12162f90, void * 0xc37b3292) line 1904 + 21 bytes
>> NK!THGetProcs(THSNAP * 0x12160000, int 1) line 1515 +
40
>> bytes
>> NK!SC_THCreateSnapshot(unsigned long 2, unsigned long
>> 1645023122) line 1681 + 34 bytes
>> COREDLL!xxx_THCreateSnapshot(unsigned long 2, unsigned
>> long 0) line 1361 + 61 bytes
>> TOOLHELP!CreateToolhelp32Snapshot(unsigned long 2,
>> unsigned long 0) line 12 + 13 bytes
>> WBTSETUP!PropPage::bIsTPTCPProcessRunning(const unsigned
>> short * const 0x00011e28) line 632 + 9 bytes
>> ...
>> where our function call to CreateToolhelp32Snapshot()
is placed in
>> function bIsTPTCPProcessRunning().
>>
>> const BOOL PropPage::bIsTPTCPProcessRunning(
>> const TCHAR* const ProcessName)
>> {
>> // TH32CS_SNAPPROCESS Includes the process list in the
>> snapshot.
>> HANDLE hSnapShot=CreateToolhelp32Snapshot
>> (TH32CS_SNAPPROCESS, 0);
>> ...
>>
>> Can anyone explain why each such call causes a
DebugBreak ?
>>
>> Thanks in advance
>>
>> Sergeir
>>
>
>
>
>.
>
- Next message: Tweeeek: "Re: SANDISK Compact FLash"
- Previous message: rcxkid: "Re: BLDR crashing in decoder??"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
|
