Differences between CVI DLL and CDB compiled from the same source...

[Joe Roberts]

(Using CVI 6.0)

We are chasing down a strange problem (see earlier thread "Intermittent
problem with TestStand calling CVI DLL calling MSVC DLL" for details) and I
have encountered something odd with the output of the CVI compiler. I don't
know if it has anything to do with the problem, but I was wondering if
someone could explain it for me...

To summarize, the problems we are seeing seem stack related. This morning
the problem showed up once again after building a DEBUG version of the CVI
DLL. I experimented around for a while trying to solve the stack problem.
At one point, I saved my DEBUG version of the DLL and source and then
compiled a RELEASE version. The problem seemed to go away. I then rebuilt
the DLL as DEBUG and the problem was still gone. I now had two DEBUG
versions of the DLL. With one, the problem occurs reliably, with the other
it never occurs.

Curious that the problem only comes and goes after compiling the CVI DLL, I
compared the two DLL binary files. Both are DEBUG and both were built from
the exact same source code (timestamps and sizes match exactly). I am
confident _none_ of the source or .LIBs changed between the two builds.

First I did a gross comparison of the output files. The two DLL files were
the same size in bytes. However, the CDB file generated differed by almost
2k (the later version was smaller). Why would that be?

I then opened the two DLL files as Binary files in the MSVC++ IDE to look at
the raw binary contents. Of course I expected some minor differences, since
the versions were build hours apart, but the results of the comparison were
surprising. The organization of the internals of the two DLLs appear very
different. The header info looked okay, but the data segments, especially
the string tables, were organized dramatically different. They are located
in very different areas in the DLL file. And the order that the strings
appear in the tables is different.

I know I did not change any project settings nor alter any source. Yet I
ended up with two different sized CDB files and two DLL files that, while
the same size, are organized very differently.

I would assume that DLLs built from the same source would be nearly
identical, even if they were built hours apart from each other, as my
versions were. Since these are both DEBUG builds, I could understand if the
data in some of the 'padded' areas were different. But I would expect that
the string tables and important program data would be in the same memory
locations. Is this a bad assumption on my part?

Is there a reason I would get a CDB file that is a different size? Is there
a valid reason the organization of the two DLLs should be different when
they are built from the same source and linked to the same .LIBs? Did my
building the RELEASE version in between cause any of these differences?

I am concerned about this because the apparent stack problems we are seeing
all seem related to strings in the CVI DLL and the string table is in
radically different memory offsets between the version that doesn't work and
the version that works.

I would suspect something corrupted in my CVI installation and try a
re-install if we had not observed this problem on two different machines
(both running Windows 2000 SP4, CVI 6.0 and TestStand 2.01f).

Any ideas, insights or comments anyone could offer would be much
appreciated.

---
Joe

[Chris Matthews]

I would suspect that the problem actually exists in both versions of the DLL, you are just seeing it cause and error or an overflow in the debug version due to different memory location and CVI's debugger checking for problems. There shouldn't be any functional differences in the DLL that would cause this, it is more likely an effect change of an error that exists in both versions. Stack and memory errors can frequently exist in your coding and not cause problems because you get lucky and they don't overwrite anything important. Just my guess at why you are seeing the difference.

Best Regards,

Chris Matthews
National Instruments

[bilalD]

Hello

Looking at the raw binary isnt really going to decipher much about the dll. Even though it looks differenbt, your dll should still be organized in the same way. To have a better understanding of this, you should use utilities like the PE Explorer that break this down for you.
The cdb file is used only by the debugger, and should not affect the behavior of your dll.

As Elain had mentioned, if you do have some code we can use to try to reproduce the problem, that would help also


Bilal Durrani
NI

[Joe Roberts]

> Looking at the raw binary isnt really going to decipher much about the
> dll. Even though it looks differenbt, your dll should still be
> organized in the same way. To have a better understanding of this, you
> should use utilities like the PE
> Explorer that break this down for you.

I was curious as to why the offset of the raw string literals was almost 2k
different between the two builds and why CDB file size was almost 2k
different. Is such differences from the same source possible?

> The cdb file is used only by the debugger, and should not affect the
> behavior of your dll.

Pure hypothetical: can incorrect or corrupted CDB information possibly cause
the CVI debugger to incorrectly flag errors in executing De
bug build code?

The reason I ask is because of the difference in CDB file size for version
that works and version that does not.

> As Elain had mentioned, if you do have some code we can use to try to
> reproduce the problem, that would help also

I will send it if and when I can reduce the problem and I can reliably
reproduce the problem.

Thanks.

---
Joe

[Joe Roberts]

> I would suspect that the problem actually exists in both versions of
> the DLL, you are just seeing it cause and error or an overflow in the
> debug version due to different memory location and CVI's debugger
> checking for problems. There shouldn't be any functional differences
> in the DLL that would cause this, it is more likely an effect change
> of an error that exists in both versions. Stack and memory errors can
> frequently exist in your coding and not cause problems because you get
> lucky and they don't overwrite anything important. Just my guess at
> why you are seeing the difference.

Both versions (the one that works and the one that does not work) are Debug
builds. Both were built from the exact same source code c filr, using the
same he
ader .h files, the same project file and linked to the same .LIBs.
The only difference I am aware of is that the two versions were built
several hours apart. I know the source and project files did not change
because I saved them off after building the broken version and used this
saved code - with no changes - to eventually build the version that somehow
works. And the code still had the date and timestamp of the first version.

Thats why I was curious as to the differences in the CDB file size and DLL
internal organization. I don't know that these differences are an issue.
Its just that I would have thought the output of two Debug builds from the
same source would have produced output 99.99% the same (barring date and
time inforation). Yet my two CDB files differ in size by almost 2k and the
raw data in the DLLs appears different - at least when looked at through the
MSVC IDE.

Thanks,

---
Joe