[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.vb.general.discussion

Eureka

Mayayana

8/27/2011 10:00:00 PM

I've been working on a mime filter for weeks with
very erratic crashes, especially in Win7, but finally
found the cause. APIViewer2004 has this declare
for CoTaskMemFree:

Private Declare Sub CoTaskMemFree Lib "ole32.dll" (ByRef pv As Any)

I changed it to ByVal pv as Long and now everything
is fine. .... For future reference.
8 Answers

Thorsten Albers

8/27/2011 10:16:00 PM

0

Mayayana <mayayana@invalid.nospam> schrieb im Beitrag
<j3bp81$qfs$1@dont-email.me>...
> Private Declare Sub CoTaskMemFree Lib "ole32.dll" (ByRef pv As Any)
>
> I changed it to ByVal pv as Long and now everything
> is fine. .... For future reference.

"For future reference" doesn't make much sense with a function where the
declaration mostly depends on the user and his use of the function. In
other words: 'ByRef' is >>in no way<< wrong and didn't cause the crash.
What caused the crash was you passing the argument in a way not appropriate
for this declaration.

--
Thorsten Albers

gudea at gmx.de

Dee Earley

8/31/2011 10:00:00 AM

0

On 27/08/2011 23:16, Thorsten Albers wrote:
> Mayayana<mayayana@invalid.nospam> schrieb im Beitrag
> <j3bp81$qfs$1@dont-email.me>...
>> Private Declare Sub CoTaskMemFree Lib "ole32.dll" (ByRef pv As Any)
>>
>> I changed it to ByVal pv as Long and now everything
>> is fine. .... For future reference.
>
> "For future reference" doesn't make much sense with a function where the
> declaration mostly depends on the user and his use of the function. In
> other words: 'ByRef' is>>in no way<< wrong and didn't cause the crash.
> What caused the crash was you passing the argument in a way not appropriate
> for this declaration.

And so:
CoTaskMemFree ByVal 0
would have had the same effect.

--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk...

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

Dee Earley

8/31/2011 10:00:00 AM

0

On 31/08/2011 10:59, Deanna Earley wrote:
> On 27/08/2011 23:16, Thorsten Albers wrote:
>> Mayayana<mayayana@invalid.nospam> schrieb im Beitrag
>> <j3bp81$qfs$1@dont-email.me>...
>>> Private Declare Sub CoTaskMemFree Lib "ole32.dll" (ByRef pv As Any)
>>>
>>> I changed it to ByVal pv as Long and now everything
>>> is fine. .... For future reference.
>>
>> "For future reference" doesn't make much sense with a function where the
>> declaration mostly depends on the user and his use of the function. In
>> other words: 'ByRef' is>>in no way<< wrong and didn't cause the crash.
>> What caused the crash was you passing the argument in a way not
>> appropriate
>> for this declaration.
>
> And so:
> CoTaskMemFree ByVal 0
> would have had the same effect.
(or rather the correct pointer value)

--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk...

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

MikeD

8/31/2011 12:01:00 PM

0



"Deanna Earley" <dee.earley@icode.co.uk> wrote in message
news:j3l0mc$nk5$1@speranza.aioe.org...
> On 27/08/2011 23:16, Thorsten Albers wrote:
>> Mayayana<mayayana@invalid.nospam> schrieb im Beitrag
>> <j3bp81$qfs$1@dont-email.me>...
>>> Private Declare Sub CoTaskMemFree Lib "ole32.dll" (ByRef pv As Any)
>>>
>>> I changed it to ByVal pv as Long and now everything
>>> is fine. .... For future reference.
>>
>> "For future reference" doesn't make much sense with a function where the
>> declaration mostly depends on the user and his use of the function. In
>> other words: 'ByRef' is>>in no way<< wrong and didn't cause the crash.
>> What caused the crash was you passing the argument in a way not
>> appropriate
>> for this declaration.
>
> And so:
> CoTaskMemFree ByVal 0
> would have had the same effect.


You should also pass 0& rather than just 0. This is because Windows is
expecting a 4 byte value for the parameter. Granted, in *most* cases this is
not an issue, but there are some API functions where passing 0 when a Long
is expected will cause problems. IMO, better safe than sorry, so I always
pass 0& when the parameter's expected data type is a Long and it's declared
As Any.

--
Mike

Mayayana

8/31/2011 12:29:00 PM

0

| so I always
| pass 0& when the parameter's expected data type is a Long and it's
declared
| As Any.
|

I thought Thorsten was just being cranky. The function
is expecting a long numeric value that represents a memory
address. Why would anyone declare that ByRef as Any?
Then, as you and Deanna have pointed out, it needs
special care. To me that seems like a error in APIViewer.
It's always expecting a long pointer, so it should always
be ByVal Long. (Unless there's some unrelated use of
CoTaskMemFree that I'm not aware of.) It's not an error
to say that Acme Drug is on the next street over from Maple
St., but there's no reason not to just say it's on Oak St.,
so that the directee doesn't have to calculate from your
directions.

I wasn't really familiar with the function, so I just copied
and pasted it. And that got me into trouble. (I was busy
swearing at MS for apparently breaking mime filter functionality
in Vista/7. :)

My warning for future reference was really about two
things. One was a note for anyone using that function
to be aware of possible differences in a typical declare.
The other was about the unpredictable nature of the
error. That probably should have been a clue to memory
issues, I suppose. But it was also interesting to see how
different systems dealt with that. On XP it usually didn't
crash. On Win7 it always crashed.


Dee Earley

8/31/2011 12:44:00 PM

0

On 31/08/2011 13:29, Mayayana wrote:
> | so I always
> | pass 0& when the parameter's expected data type is a Long and it's
> declared
> | As Any.
> |
>
> I thought Thorsten was just being cranky. The function
> is expecting a long numeric value that represents a memory
> address. Why would anyone declare that ByRef as Any?

I admit in VB6 it's kinda silly as it "doesn't do pointers", and you'd
only ever pass a pointer variable.

> Then, as you and Deanna have pointed out, it needs
> special care. To me that seems like a error in APIViewer.
> It's always expecting a long pointer, so it should always
> be ByVal Long. (Unless there's some unrelated use of
> CoTaskMemFree that I'm not aware of.)

Not in VB6.

> I wasn't really familiar with the function, so I just copied
> and pasted it.

There's your problem :p

> But it was also interesting to see how different systems dealt with
> that. On XP it usually didn't crash. On Win7 it always crashed.

It depends on what memory was allocated around it and many other factors.

Interestingly, my site had the (more) correct version:
http://www.earlsoft.co.uk/api/call.php?name=CoT...
(taken from vb api viewer plugin list)

--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk...

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

Mayayana

8/31/2011 1:22:00 PM

0


| > But it was also interesting to see how different systems dealt with
| > that. On XP it usually didn't crash. On Win7 it always crashed.
|
| It depends on what memory was allocated around it and many other factors.
|

Yes. I suppose it also depends on what I've got at the
offset. I'm guessing that windows probably starts clearing
at the address given and keeps going until it hits a null.
But I also came across some comments in my searching,
saying that Win7 is more strict in handling memory.
Unfortunately that's all I know about that. I didn't find any
explanation of the claim. For that matter, I don't know for
sure that it isn't just a mistaken rumor that grew out of
the introduction of DEP, which wasn't in the original XP.

Thorsten Albers

8/31/2011 6:11:00 PM

0

Mayayana <mayayana@invalid.nospam> schrieb im Beitrag
<j3l99u$ela$1@dont-email.me>...
> I thought Thorsten was just being cranky.

No, he wasn't.

> The function
> is expecting a long numeric value that represents a memory
> address.

No, the function is expecting a memory address with a 'width' of 4 bytes of
memory. How these 4 bytes are passed to the function doesn't matter at all.
You may declare it 'As Any', 'As Long', 'As Single', pass a byte array with
4 elements, etc. CoTaskMemFree() doesn't know anything about what data type
it is in VB, it just reads 4 bytes from the stack and uses these as a
pointer.

And that is valid not only for CoTaskMemFree() but for any Declare
statement in VB:
You only have to ensure that
- the correct number of bytes is passed, and
- that the values of the bytes are correct.

The data type used with the Declare statement in VB is only a help for the
VB developer to pass the correct amount of bytes as well as the correct
byte values. With external functions there is no need that it is of the
same data type as used by the function.

--
Thorsten Albers

gudea at gmx.de