Re: VerQueryValue Bug?

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.



"Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> wrote in message
news:%23$NFtz$SFHA.2880@xxxxxxxxxxxxxxxxxxxxxxx
> The heap check is only performed when yuou run under debugger.
>
> You may need to post a larger piece of code.
>
> "Rob Smitter" <rsmitter@xxxxxxxxxxxx> wrote in message
> news:%23bLl4O$SFHA.2256@xxxxxxxxxxxxxxxxxxxxxxx
> > 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.
> >
> >
> > "Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> wrote in message
> > news:OqJy$05SFHA.3840@xxxxxxxxxxxxxxxxxxxxxxx
> >> You should NOT be using whavever returned in pstrResult after you free
> > 'p'.
> >>
> >> "Rob Smitter" <rsmitter@xxxxxxxxxxxx> wrote in message
> >> news:%23sUOkg4SFHA.3936@xxxxxxxxxxxxxxxxxxxxxxx
> >> > 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.
> >> >
> >> >
> >>
> >>
> >
> >
>
>


.

Relevant Pages

  • Re: Strange C error
    ... Getting debug output back via wimp error boxes sounds a bit painful! ... is the length of the icon's buffer? ... variables in a function with gcc? ...
    (comp.sys.acorn.programmer)
  • Re: cxx0017: ... symbol not found VC++6
    ... You are running a debug build of the project with debug symbols ... // At this point should be pointing at workingBuf at the point of the ... // buffer end is reached before a $ is found the device should be ... // First check for end of buffer and read input buffer (newBuf) if ...
    (microsoft.public.vc.language)
  • Re: VerQueryValue Bug?
    ... call to verqueryvalue was not called there was not problem. ... Allocated a buffer ... our own and allocate it. ... VerQueryValue has an effect on the memory in debug mode ...
    (microsoft.public.win32.programmer.kernel)
  • Re: waveINxxx "bad pointer" error in Debug version
    ... This seems to indicate something with the debug rt library causing the ... preparing the buffers once, receiving full buffers for MM_WIM_DATA and ... The pointer pwaveHdr1 is in your data section so if the pointer ... _wctime_s needs a buffer of 26 characters. ...
    (microsoft.public.win32.programmer.mmedia)
  • LoadUserProfile() returns ERROR_ACCESS_DENIED
    ... GetLastError() returns 5 ... debug(buffer); ... debug("Couldn't set 'SE_ASSIGNPRIMARYTOKEN_NAME' privilege for this ...
    (microsoft.public.platformsdk.security)