Discussion:
VerQueryValue Bug?
(too old to reply)
Rob Smitter
2006-06-14 04:13:59 UTC
Permalink
Is there any known problem with VerQueryValue.

An example of how I am using it is:

wchar_t* pstrResult = NULL;
unsigned int VersionLength = 0;

if (VerQueryValue(p, L"\\StringFileInfo\\040904e4\\FileVersion",
pstrInfoName", (void **)&pstrResult, (unsigned int *)&VersionLength)) {
...
}

where p is a pointer to the resource.

As a side note, we do not use GetFileVersionInfo to get P but derive it. on
our own and allocate it.

The symptom is this -

If we make the call to VerQueryValue and then delete p, and only in debug
mode, we get a runtime error

HEAP[Test.exe]: HEAP: Free Heap block 8a34a8 modified at 8a3624 after it was
freed
Unhandled exception at 0x77f75a58 in Test.exe: User breakpoint

If we skip the call to VerQueryVal\lue and delete it all is well. It seems
VerQueryValue has an effect on the memory in debug mode

In (we are compiling multithreaded debug)

_CRTIMP void __cdecl _free_dbg(

at these lines:

/* fill the entire block including header with dead-land-fill */
memset(pHead, _bDeadLandFill, sizeof(_CrtMemBlockHeader) + pHead->nDataSize
+ nNoMansLandSize);
_free_base(pHead);

When _free_base(pHead) is called it calls

HeapFree(_crtheap, 0, pBlock);

Then we get the errors mentioned above.

Any information on if there is known issue would be most appreciated.
Again, the point is that the call to VerQueryValue is the only thing that
gets done and the problem appears. I have even copied the version block
into another buffer I allocated just before the call and did a delete after
and it causes the problem. By copying to a stack variable I made large
enough to handle the data all seemed fine.

Another note - no problem when running in debug mode using start without
debugging. Only when doing a normal start. VC 7 Visual C++.net

Thanks much for any help.
Alexander Grigoriev
2005-04-28 02:51:56 UTC
Permalink
You should NOT be using whavever returned in pstrResult after you free 'p'.
Post by Rob Smitter
Is there any known problem with VerQueryValue.
wchar_t* pstrResult = NULL;
unsigned int VersionLength = 0;
if (VerQueryValue(p, L"\\StringFileInfo\\040904e4\\FileVersion",
pstrInfoName", (void **)&pstrResult, (unsigned int *)&VersionLength)) {
...
}
where p is a pointer to the resource.
As a side note, we do not use GetFileVersionInfo to get P but derive it. on
our own and allocate it.
The symptom is this -
If we make the call to VerQueryValue and then delete p, and only in debug
mode, we get a runtime error
HEAP[Test.exe]: HEAP: Free Heap block 8a34a8 modified at 8a3624 after it was
freed
Unhandled exception at 0x77f75a58 in Test.exe: User breakpoint
If we skip the call to VerQueryVal\lue and delete it all is well. It seems
VerQueryValue has an effect on the memory in debug mode
In (we are compiling multithreaded debug)
_CRTIMP void __cdecl _free_dbg(
/* fill the entire block including header with dead-land-fill */
memset(pHead, _bDeadLandFill, sizeof(_CrtMemBlockHeader) +
pHead->nDataSize
+ nNoMansLandSize);
_free_base(pHead);
When _free_base(pHead) is called it calls
HeapFree(_crtheap, 0, pBlock);
Then we get the errors mentioned above.
Any information on if there is known issue would be most appreciated.
Again, the point is that the call to VerQueryValue is the only thing that
gets done and the problem appears. I have even copied the version block
into another buffer I allocated just before the call and did a delete after
and it causes the problem. By copying to a stack variable I made large
enough to handle the data all seemed fine.
Another note - no problem when running in debug mode using start without
debugging. Only when doing a normal start. VC 7 Visual C++.net
Thanks much for any help.
Rob Smitter
2005-04-28 13:10:54 UTC
Permalink
That is not the issue. The test I made was not even using the result. To
test out what was happening it did just:

Allocated a buffer
Copy the resource block into the buffer
Call VerQueryValue
delete the buffer - exception gets called

Only in debug mode when stepping through the code

The result, pstrResult, did have the correct data in it. It was never used,
never saved. The issue is that it seems VerQueryValue has either a bug in
debug mode or the debug memory free has a problem.
Post by Alexander Grigoriev
You should NOT be using whavever returned in pstrResult after you free 'p'.
Post by Rob Smitter
Is there any known problem with VerQueryValue.
wchar_t* pstrResult = NULL;
unsigned int VersionLength = 0;
if (VerQueryValue(p, L"\\StringFileInfo\\040904e4\\FileVersion",
pstrInfoName", (void **)&pstrResult, (unsigned int *)&VersionLength)) {
...
}
where p is a pointer to the resource.
As a side note, we do not use GetFileVersionInfo to get P but derive
it.
Post by Alexander Grigoriev
Post by Rob Smitter
on
our own and allocate it.
The symptom is this -
If we make the call to VerQueryValue and then delete p, and only in debug
mode, we get a runtime error
HEAP[Test.exe]: HEAP: Free Heap block 8a34a8 modified at 8a3624 after it was
freed
Unhandled exception at 0x77f75a58 in Test.exe: User breakpoint
If we skip the call to VerQueryVal\lue and delete it all is well. It seems
VerQueryValue has an effect on the memory in debug mode
In (we are compiling multithreaded debug)
_CRTIMP void __cdecl _free_dbg(
/* fill the entire block including header with dead-land-fill */
memset(pHead, _bDeadLandFill, sizeof(_CrtMemBlockHeader) +
pHead->nDataSize
+ nNoMansLandSize);
_free_base(pHead);
When _free_base(pHead) is called it calls
HeapFree(_crtheap, 0, pBlock);
Then we get the errors mentioned above.
Any information on if there is known issue would be most appreciated.
Again, the point is that the call to VerQueryValue is the only thing that
gets done and the problem appears. I have even copied the version block
into another buffer I allocated just before the call and did a delete after
and it causes the problem. By copying to a stack variable I made large
enough to handle the data all seemed fine.
Another note - no problem when running in debug mode using start without
debugging. Only when doing a normal start. VC 7 Visual C++.net
Thanks much for any help.
Alexander Grigoriev
2005-04-28 14:16:48 UTC
Permalink
The heap check is only performed when yuou run under debugger.

You may need to post a larger piece of code.
Post by Rob Smitter
That is not the issue. The test I made was not even using the result. To
Allocated a buffer
Copy the resource block into the buffer
Call VerQueryValue
delete the buffer - exception gets called
Only in debug mode when stepping through the code
The result, pstrResult, did have the correct data in it. It was never used,
never saved. The issue is that it seems VerQueryValue has either a bug in
debug mode or the debug memory free has a problem.
Post by Alexander Grigoriev
You should NOT be using whavever returned in pstrResult after you free
'p'.
Post by Alexander Grigoriev
Post by Rob Smitter
Is there any known problem with VerQueryValue.
wchar_t* pstrResult = NULL;
unsigned int VersionLength = 0;
if (VerQueryValue(p, L"\\StringFileInfo\\040904e4\\FileVersion",
pstrInfoName", (void **)&pstrResult, (unsigned int *)&VersionLength)) {
...
}
where p is a pointer to the resource.
As a side note, we do not use GetFileVersionInfo to get P but derive
it.
Post by Alexander Grigoriev
Post by Rob Smitter
on
our own and allocate it.
The symptom is this -
If we make the call to VerQueryValue and then delete p, and only in
debug
Post by Alexander Grigoriev
Post by Rob Smitter
mode, we get a runtime error
HEAP[Test.exe]: HEAP: Free Heap block 8a34a8 modified at 8a3624 after
it
was
freed
Unhandled exception at 0x77f75a58 in Test.exe: User breakpoint
If we skip the call to VerQueryVal\lue and delete it all is well. It seems
VerQueryValue has an effect on the memory in debug mode
In (we are compiling multithreaded debug)
_CRTIMP void __cdecl _free_dbg(
/* fill the entire block including header with dead-land-fill */
memset(pHead, _bDeadLandFill, sizeof(_CrtMemBlockHeader) +
pHead->nDataSize
+ nNoMansLandSize);
_free_base(pHead);
When _free_base(pHead) is called it calls
HeapFree(_crtheap, 0, pBlock);
Then we get the errors mentioned above.
Any information on if there is known issue would be most appreciated.
Again, the point is that the call to VerQueryValue is the only thing
that
Post by Alexander Grigoriev
Post by Rob Smitter
gets done and the problem appears. I have even copied the version block
into another buffer I allocated just before the call and did a delete after
and it causes the problem. By copying to a stack variable I made large
enough to handle the data all seemed fine.
Another note - no problem when running in debug mode using start without
debugging. Only when doing a normal start. VC 7 Visual C++.net
Thanks much for any help.
Rob Smitter
2006-06-14 04:14:00 UTC
Permalink
Interesting result - When I changed the code that allocated the allocated
the buffer for the resouce block from a

Buf = new BYTE[size] followed by a delete []Buf

to a malloc and a free, the debug exception issue went away

There were other things that I needed to change in the actual code (non test
case) other code also related to using wstring variables declared local to
the function that verqueryvalue was called from. When they were going out
of scope, and onl;y in the debugger the same thing would happen. And if the
call to verqueryvalue was not called there was not problem.

I believe that debug and verqueryvalue can have unexpected side effects. I
have used it many times and only under these circumstances has this
happened.
Post by Alexander Grigoriev
The heap check is only performed when yuou run under debugger.
You may need to post a larger piece of code.
Post by Rob Smitter
That is not the issue. The test I made was not even using the result.
To
Post by Alexander Grigoriev
Post by Rob Smitter
Allocated a buffer
Copy the resource block into the buffer
Call VerQueryValue
delete the buffer - exception gets called
Only in debug mode when stepping through the code
The result, pstrResult, did have the correct data in it. It was never used,
never saved. The issue is that it seems VerQueryValue has either a bug in
debug mode or the debug memory free has a problem.
Post by Alexander Grigoriev
You should NOT be using whavever returned in pstrResult after you free
'p'.
Post by Alexander Grigoriev
Post by Rob Smitter
Is there any known problem with VerQueryValue.
wchar_t* pstrResult = NULL;
unsigned int VersionLength = 0;
if (VerQueryValue(p, L"\\StringFileInfo\\040904e4\\FileVersion",
pstrInfoName", (void **)&pstrResult, (unsigned int *)&VersionLength)) {
...
}
where p is a pointer to the resource.
As a side note, we do not use GetFileVersionInfo to get P but derive
it.
Post by Alexander Grigoriev
Post by Rob Smitter
on
our own and allocate it.
The symptom is this -
If we make the call to VerQueryValue and then delete p, and only in
debug
Post by Alexander Grigoriev
Post by Rob Smitter
mode, we get a runtime error
HEAP[Test.exe]: HEAP: Free Heap block 8a34a8 modified at 8a3624 after
it
was
freed
Unhandled exception at 0x77f75a58 in Test.exe: User breakpoint
If we skip the call to VerQueryVal\lue and delete it all is well. It seems
VerQueryValue has an effect on the memory in debug mode
In (we are compiling multithreaded debug)
_CRTIMP void __cdecl _free_dbg(
/* fill the entire block including header with dead-land-fill */
memset(pHead, _bDeadLandFill, sizeof(_CrtMemBlockHeader) + pHead->nDataSize
+ nNoMansLandSize);
_free_base(pHead);
When _free_base(pHead) is called it calls
HeapFree(_crtheap, 0, pBlock);
Then we get the errors mentioned above.
Any information on if there is known issue would be most appreciated.
Again, the point is that the call to VerQueryValue is the only thing
that
Post by Alexander Grigoriev
Post by Rob Smitter
gets done and the problem appears. I have even copied the version block
into another buffer I allocated just before the call and did a delete after
and it causes the problem. By copying to a stack variable I made large
enough to handle the data all seemed fine.
Another note - no problem when running in debug mode using start without
debugging. Only when doing a normal start. VC 7 Visual C++.net
Thanks much for any help.
Alexander Grigoriev
2005-04-29 03:07:07 UTC
Permalink
The heap corruption might have been happened in other cases, but heap check
is only performed when the application runs under debugger.

You need to find the exact cause of the problem, not just settle when some
unrelated changes seem to make the problem disappear.

Make sure you didn't write 'new BYTE(size)'.
Post by Rob Smitter
Interesting result - When I changed the code that allocated the allocated
the buffer for the resouce block from a
Buf = new BYTE[size] followed by a delete []Buf
to a malloc and a free, the debug exception issue went away
There were other things that I needed to change in the actual code (non test
case) other code also related to using wstring variables declared local to
the function that verqueryvalue was called from. When they were going out
of scope, and onl;y in the debugger the same thing would happen. And if the
call to verqueryvalue was not called there was not problem.
I believe that debug and verqueryvalue can have unexpected side effects.
I
have used it many times and only under these circumstances has this
happened.
Post by Alexander Grigoriev
The heap check is only performed when yuou run under debugger.
You may need to post a larger piece of code.
Post by Rob Smitter
That is not the issue. The test I made was not even using the result.
To
Post by Alexander Grigoriev
Post by Rob Smitter
Allocated a buffer
Copy the resource block into the buffer
Call VerQueryValue
delete the buffer - exception gets called
Only in debug mode when stepping through the code
The result, pstrResult, did have the correct data in it. It was never used,
never saved. The issue is that it seems VerQueryValue has either a bug
in
Post by Alexander Grigoriev
Post by Rob Smitter
debug mode or the debug memory free has a problem.
Post by Alexander Grigoriev
You should NOT be using whavever returned in pstrResult after you free
'p'.
Post by Alexander Grigoriev
Post by Rob Smitter
Is there any known problem with VerQueryValue.
wchar_t* pstrResult = NULL;
unsigned int VersionLength = 0;
if (VerQueryValue(p, L"\\StringFileInfo\\040904e4\\FileVersion",
pstrInfoName", (void **)&pstrResult, (unsigned int
*)&VersionLength))
{
Post by Alexander Grigoriev
Post by Rob Smitter
Post by Alexander Grigoriev
Post by Rob Smitter
...
}
where p is a pointer to the resource.
As a side note, we do not use GetFileVersionInfo to get P but derive
it.
Post by Alexander Grigoriev
Post by Rob Smitter
on
our own and allocate it.
The symptom is this -
If we make the call to VerQueryValue and then delete p, and only in
debug
Post by Alexander Grigoriev
Post by Rob Smitter
mode, we get a runtime error
HEAP[Test.exe]: HEAP: Free Heap block 8a34a8 modified at 8a3624 after
it
was
freed
Unhandled exception at 0x77f75a58 in Test.exe: User breakpoint
If we skip the call to VerQueryVal\lue and delete it all is well.
It
seems
VerQueryValue has an effect on the memory in debug mode
In (we are compiling multithreaded debug)
_CRTIMP void __cdecl _free_dbg(
/* fill the entire block including header with dead-land-fill */
memset(pHead, _bDeadLandFill, sizeof(_CrtMemBlockHeader) + pHead->nDataSize
+ nNoMansLandSize);
_free_base(pHead);
When _free_base(pHead) is called it calls
HeapFree(_crtheap, 0, pBlock);
Then we get the errors mentioned above.
Any information on if there is known issue would be most
appreciated.
Again, the point is that the call to VerQueryValue is the only thing
that
Post by Alexander Grigoriev
Post by Rob Smitter
gets done and the problem appears. I have even copied the version block
into another buffer I allocated just before the call and did a
delete
after
and it causes the problem. By copying to a stack variable I made
large
Post by Alexander Grigoriev
Post by Rob Smitter
Post by Alexander Grigoriev
Post by Rob Smitter
enough to handle the data all seemed fine.
Another note - no problem when running in debug mode using start without
debugging. Only when doing a normal start. VC 7 Visual C++.net
Thanks much for any help.
Loading...