CVI9.0 after building distribution disk, getting internal error 001b:104fb24c

[msaxon]

I'm afraid I could not deliver the project to you without an NDA with NI (which I understand are very hard to arrange).

The quoted address is always 001B:104FB24C.

[rorOttawa]

NI have a utility called msiblast.exe to delete all entries for NI in the registry.

[LuisG]

Hello,

These questions are directed at both rorOttawa and Martin, since both of you seem to have run into the same crash.

1. Does the crash only happen when following the steps described by rorOttawa in the first two posts in the thread?

2. When following those steps, does the crasg always happen, or only sometimes?

3. Does it happen with any project for which you're building a distribution? Can you reproduce the crash when building a distribution for one of CVI's example programs?

Luis

[rorOttawa]

For Me it happened every time on that one project.

I have not had time to try it on a sample, i will do this within the next week.

BTW I think this CVI9 with resource tracking feature is the best thing that I have seen from NI software for years.

Thanks alot.

[msaxon]

Mert:

I have worked around the issue by creating an entrely new project in CVI 9.0, built from the same source. All of the problems have now gone away. It looks like the distribution configuration mechanism in CVI 9 doesn't like [some] projects originally created in an older version of CVI. I took a cursory look at the old and new project files, but I can't see any differences between them that look significant.

Message Edited by msaxon on 03-20-2009 12:19 PM

[msaxon]

Mert:

Actually there is one possibly significant difference between the project files:

The new file that works has the entry:

Flags = 2064

in the [Project Header] section, whereas the one that doesn' work has

Flags = 16

---

msaxon wrote:

Mert:

I have worked around the issue by creating an entrely new project in CVI 9.0, built from the same source. All of the problems have now gone away. It looks like the distribution configuration mechanism in CVI 9 doesn't like [some] projects originally created in an older version of CVI. I took a cursory look at the old and new project files, but I can't see any differences between them that look significant.

Message Edited by msaxon on 03-20-2009 12:19 PM

---

[msaxon]

Mert:

Whilst I cannot give you the source code, I have uploaded a zip file containing both 'good' and 'bad' project files to ftp://ftp.ni.com/incoming. The file is 'GOODBAD.ZIP'.

I can confirm that replacing the 'good' project file with the 'bad' project file causes CVI to crash on exit as reported. Putting the 'good' project file back again cures the crash.

[Mert_A.]

That is great. I'll let you know what I find. We really appreciate your help with this issue.

Mert A.

National Instruments

[Mert_A.]

Found it. It turns out that there is an obscure bug that comes into play when unloading the workspace if:

• there is a configured distribution that includes the project output, and
• the project's target file (Application File in the Target Settings dialog) is not an absolute path.

You'll notice that in BAD.prj, this path is just "2100D2_1553_01A.exe" whereas in GOOD.prj it is a full, absolute path. The typical situation is that the path is absolute, since this setting defaults to an absolute path, and the Browse button also inserts an absolute path. This explains the relative rarity of this issue.

The problem is resolved by replacing the filename-only path with a full path. Note that even when a full, absolute path is provided here, if the file is actually relative to the project, it will be tracked as such. There is no behavioral gain by providing only the filename-only path.

We'll be sure to fix the original bug in the next maintenance release. Thanks again for helping us track down the source!

Mert A.

National Instruments

[msaxon]

In that case, I can end the week feeling that I've achieved something