VS2010 crashes with BSOD when target Framework is changed

[Grant_LECO]

I thoguht I needed to chime in on this since I have a developement station that is identical to your second station and I just had a nipalk.sys BSOD dump when I my computer came out of standby mode this morning.  Maybe it had crashed last night but that's irrelavent.  I came back to this site to get the

 <PropertyGroup>
    <TrackFileAccess>false</TrackFileAccess>
  </PropertyGroup>

code that I put in all my .csproj files that reference NI assemblies.  I just referenced assemblies in this particular project for the first time yesterday and forgot to add this tag. I've been working with this project off and one for 3 months now without any issues. After I put this tag in place this morning I'll start getting some runtime. 

I always paste the tag at the end of the .csproj file like this

...

...

..

..

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <!-- To modify your build process, add your task inside one of the targets below and uncomment it.
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>
  -->
   <PropertyGroup>
    <TrackFileAccess>false</TrackFileAccess>
  </PropertyGroup>
</Project>

So far I haven't had any problems running projects on stations that are running the latest NiDaqmx, which is 9.2.3 right now I beleive, and have their .csproj file containing the above tag.

The first thing you should do is update your first station that is running 9.0.2 to 9.2.3 since it's reported by NI in previous posts that any version before 9.2.1 has issues.  Then I would try updating your .csproj file to include the above tag.

I have also had multiple corrupted installs of Visual Studio 2010 that required me to do a repair.  I think one took over 4 hours to complete on machine that is a couple of years old running a Pentium 4.  Maybe it wouldn't be so painful on a newer machine.  My only point is that I think the BSOD causes Visual Studio 2010 to become corrupted and the BSOD is caused by nipalk.sys which only seems to happen to me when I'm running projects without the

   <PropertyGroup>
    <TrackFileAccess>false</TrackFileAccess>
  </PropertyGroup>

tag in my .csproj file.

Grant

[Grant_LECO]

Update..

I tried to start Visual Studio 2010 and I got the side-by-side configuration error.  I should have checked for this before I posted my previous response.

Instead of getting some runtime this morning it looks like I'll lose another day doing another repair to VS.

I still haven't had problems with a project that references NI assemblies and has the

<PropertyGroup>
    <TrackFileAccess>false</TrackFileAccess>
  </PropertyGroup>

tag.  I'll get some runtime after the repair and post anything I find.

Grant

[Justin_E]

lorenz,

Can you try one of the two workarounds I posted on this page, and let me know if they don't resolve your BSOD? As Grant mentioned, adding the following somewhere within the <Project> tag in your .csproj file should stop your machine from blue-screening and corrupting your Visual Studio install:

  <PropertyGroup>
    <TrackFileAccess>false</TrackFileAccess>
  </PropertyGroup>

Please try one of the workarounds and let me know whether or not it resolves your issue. I apologize for the inconveniences this issue has caused everyone; we're actively investigating into this issue to provide a fix in a future release.

[lorenzpurple]

Hello

Today (before reading about the .csproj possible solution) I've already removed the .net 4 framework

from our acquistion system (I've fallen back to .net 2, that always worked)

If National DAQ is not enough mature to be used in production, as it is by now, we can't afford any

risk like casual BSOD.

We'll check back on the issue when there is more time to make such test....

best regards

[tbandtg]

This has been vexing me for about 2 weeks now. I have my ide folder backed up just so I can recopy it. It is terrible that this exists. I can honestly not believe the development time that it caused me.  I switched pcs. I have reinstalled vs ten times which is an all day thing. 

Here is a protip if you back up the files not the folders in yoru Common7\IDE folder you can get back up and running very fast.

There is no reason for National Instruments to corrupt another companies software. I can honestly say if there is a competing product from now on National Instruments looses outright.

[AbeH]

This problem is absolutely insane. I have spent the last 2 weeks trying to develop my application when all that happens is I get a BSOD followed by my VS2010 installation becoming corrupt. EVERY single time this is due to nipalk.sys.

I have performed a 100% clean Windows 7 OS installation. I would load VS2010 followed by DAQmx 9.2.3.

I have performed this on a completely different PC, same results.

I have tried targetting 4.0 framework, same results.

I have tried targetting 3.5 framework, same results.

I have tried installing VS2010 SP1 Beta, same results.

I have tried DAQmx 9.2.2, same results.

I have tried Windows XP, same results.

I am a programmer with 35 years of experience. I exhaust every possible effort before I cry for mercy. Please, fix this issue. I cannot develop my application until this is resolved. There issue is solely in National Instruments hand as I have zero issues until I install and reference DAQmx. Everything described by everyone elses post is occuring for me as well. NI you can easily reproduce this issue.

Thanks

[ralfeden]

Hi AbeH,

I have updated to DAQmx 9.2.3. and use the .NET Framework 4 in my projects. I added the following sequence somewhere within the <Project> tag to all my .csproj files that have a reference to the NI DAQ Assemblies. That stoped my machine from blue-screening and corrupting your Visual Studio install.

  <PropertyGroup>
    <TrackFileAccess>false</TrackFileAccess>
  </PropertyGroup>

After modifing the csproj files, I didn't have a BSOD until this morning. The reason was, that I added a new project to my solution that has a reference to the NI DAQ Assemblies, and I forgot to add the specified above sequence in my .csproj file.

I hope this can help you temporarily until NI has a solution for the problem

Regards,

Ralf 

[Mitch7]

I'm with you AbeH. It is quite ridiculous.

As NI has grown, they have not bothered to reorganize their software architecture. They have chosen the pile-it-all-together approach, and eventually it becomes unmaintainable (with 35 years of experinece you've probably seen this before). The pile-it-all-together design is evident in their humongous installers, and their need to install and run 14 services. Yes that's correct; FOIURTEEN. Open the service manager and count them. No wonder all the blue screens. And we're using the "streamlined" 150 MB DAQmx installer!

NI: I just need a simple driver to talk to my USB6009 IO card. Other hardware vendors do it this way without ANY services to cause BSOD. Keep it smple and your reliability will go up.

Mitch

[Tonu]

   Totally agree, streamlined, mean and lean hardware drivers are needed bad. A 100+ part installer is ridiculous for dedicated simple apps.  Altough, I understand that for developers to install the whole package might be a necessary evil.  Despite that I cut out everything that I think is excess, I still have 100+ step/part installer. And, GPIB drivers are getting there too (I think it's up to ~80 parts now).  It appears that after I cut out LabView and related parts, a large part of LabView support still remains.         

   Less talked on these pages is that there may be another guilty party here.  In my opinion, there is Microsoft's share in these crashes as well.  After all, it is MS compiler that crashes at compile time.  Given bad code and faulty libraries, it is still compiler's sole responsibility to discover all errors in the code without crashing on its own.  MS response to me was that BSOD because of their compiler is impossible. That statement sounds to me like "giraffes do not exist because this long necks are impossible".

  Could somebody from NI explain us in simple terms what is their current take what causes MS compiler to BSOD first and then sometimes also to self-destruct?  And also, how far is NI in getting the fix out?  A week, a month, or longer?

[Mitch7]

Ironically, we switched from a Measurment Computing board to the NI board because we thought it would be more robust. For our next release, we'll do another search. Any suggestions?

Mitch