VS2010 crashes with BSOD when target Framework is changed

[Grant_LECO]

Are you sure it doesn't just happen the first time you switch your project framework to 4.0? 

Here is what has been happening to me when I upgrade my VS2008 .NET 3.5 projects using MeasurementStudio 2009 to VS2010 .NET 4.0 using MeasurementStudio 2010 with NiDaqmx 9.2.3 :

0.) I save everything to my CVS system so when files are removed I can get them again.

1.) I delete the .sln and .sou files from my project root.

2.) I load the .proj file into Visual Studio 2010. 

a.) Here I get warnings about the framework being incorrect or something referring to the framework anyway.  I just ignore it.

b.) I let the project wizard update my project to 2010.  So far I haven't had any issues besides a couple of warnings that haven't hurt me.

3.) I change the framework from 3.5 to 4.0.

a.) This is where the funky stuff happens.  Files in my project root are removed.  Often the app.config file or my Form1.cs or design files get removed or renamed.

b.) Sometimes some extra files are added with very long strange names that don't mean anything to me.

4.) I save my project which creates a new .sln file.

5.) I exit VS2010.

6.) I delete any strange filenames that have shown up.

7.) I use CVS to bring back any files that were removed.

a.) So far any files that leave have left from my project root.

8.) With the files back I load the project by clicking on the new .sln file

9.) This time I come in with no warnings and expect things to work.

I have had good success with this so far but it's still early.  I've probably done it about 6 times and it's worked every time. 

Hopefully something in here helps.

Grant

[Amolf]

Hello Grant,

It's not just when upgrading to framework 4.0.

It happens also while debugging a program that has been upgraded long ago!

Have some breakpoints, run, stop, test for a while (like normal application development) and it will happen!

In some cases you get the BSOD with the nipalk.sys crashing.. but mostly it's just your files (either sources or build executables/dll) getting deleted and "pimmInternalFloatingSharedHead" being created!

My experience is that once nipalk.sys has become 'unstable' it will delete your files on every run of your application, not only debug build, but also release built, and also when you run it outside of visual studio!

I hope that this description will give you some clues on how to solve this bug.  It is very very annoying.

I would say that working with NI DaqMx and .NET is impossible at this stage.

Best regards,

Marco

Win7 x64, VS2010 PRO SP1, NI-DAQ 9.2.3, .NET 4.0

[Grant_LECO]

Marco,

First let me say that I don't represent NI in any way, shape, or form so please take all my comments/suggestions with that in mind.

I wanted to revise my previous post based on what I just saw on another project I was updating.

I should also mention that I'm running XP SP3 in case 32bit development has anything to do with this issue.

I updated my project as before and didn't have any issues with files being removed.

I would have told you before that after I updated a project and saved it as a new .sln file that when I ran the project from the new .sln file that there weren't any more problems after that.  That is no longer the case.  I ran my updated project via the updated .sln file and when I changed something in one of my project files, I believe it was something in Form1.cs (what ever the main or initial project file is for your Windows Forms project which should also be mentioned that this is all based on using Windows Forms projects), then I saw files disappear and the file you mentioned earlier be added. 

However, I was able to get up and going again by exiting the project, deleting any modified files such as the .sln file, the .sou (.suo?)  and maybe the .user.proj file, and bringing them down again from the repository.  When I went back into my project via the .sln file that I first created when I updated my project I was able to make changes without seeing any files disappearing or getting renamed.  At this point I thought I was all clear but when I went to shut down windows I got the nipalk.sys BSOD.  I didn't have any more problems in my project however.  I'm basically finished with these projects so I'm just updating them without making any code changes so I could be missing something there.

I think the whole idea you mentioned of nipalk.sys going unstable is an accurate one.  Regardless of whatever causes it to become unstable once nipalk.sys reaches that state it's a wild card as to how it's going to show itself. 

The only thing I might still have to offer is to restart windows once you get your project the way you like it.  I'm assuming that you see occasional glimpses of the project working the way you like only to have problems show up again. I have yet to have nipalk.sys problems after rebooting and running only VS2010 projects that were updated using the procedure I outlined previously.  I am nowhere near confident that I won't have future problems however.

Grant

[Justin_E]

For those of you who are still getting this error after targeting .NET 4.0 and using DAQmx 9.2.3 (sww and Amolf), have you tried this other workaround:

Add the following somewhere within the <Project> tag in your .csproj file:

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

If so, did this also not resolve the issue?

[Amolf]

 Hi Justin E,

I have not tried this workaround yet. The solution I am currently working on contains 13 project files. Do I need to put this Property in all, or just the one's that reference the NI-DAQ assemblies, or in the executable-assembly?

Best Regards,

Marco, Amolf

[ralfeden]

Hi Justin E,

I have tried the workaround with the  <TrackFileAccess>false</TrackFileAccess> in all my .csproj - files. For 2 days I got no error, but today the problem occured again. This workaround doesn' t also fix the problem. What I did is that I started a remote debug session with VS studio 2010 to test an application on another machine that uses the NI-DAQmx components. After finishing the debug session I shut down my Visual Studio 2010. Later I tried to start VS 2010 again, but no way. I got the same error message, as a described in my post from november 18th: "this application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem". Im using VS 2010, .NET Framework 3.5 on WinXP PRO SP 3 with the NI-DAQmx components Version 9.0.2.

I tried to restart my PC and got a BSOD (nipalk.sys).

Regards,

Ralf 

[Grant_LECO]

Ralf,

I installed VS2010 on a machine running VS2008 and then installed MeasurementStudio 2010 along side MeasurementStudio 2009.  I then put the latest NiDaqmx (9.2.3 I believe) on the machine that had 9.0.2 of NiDaqmx.  When I converted my first project that was built against .NET 3.5 to .NET 4.0 I got the nipalk.sys problem and something corrupted my Visual Studio 2010 installation.  After this I was unable to open Visual Studio at all without getting the message you got :

"this application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem".

I put in my Visual Studio 2010 disk and told it to repair the installation.  This allowed me to get into Visual Studio 2010 again.  I thought that might be useful to you since it looks like reinstalling the application (which in this case was Visual Studio 2010 and was accomplished using the repair option) actually seemed to work.

Also, I haven't done anything with <TrackFileAccess>false</TrackFileAccess> in all my .csproj files.  I have trouble converting my projects .NET 4.0 initially but then things seem to work once I restore any files that get removed.  However, five mintues ago I just crashed right out of my "working" project and I was wondering if adding <TrackFileAccess>false</TrackFileAccess> in all my .csproj files was supposed to help with intermittancies after the program has been running for awhile.

One more though.

You mentioned

"Im using VS 2010, .NET Framework 3.5 on WinXP PRO SP 3 with the NI-DAQmx components Version 9.0.2."

Don't you want to build against .NET 4.0 if you are using VS2010?  If you are building against 3.5 then wouldn't you just want to stay with VS2008 and Mesurement Studio 2009 and the previous version of NiDaqmx which I believe was 9.0.2?  I thought the problem here was people wanted to use Visual Studio 2010 to develope .NET 4.0 apps and were having trouble porting their projects over from VS2008 and .NET 3.5 to VS2010 and .NET 4.0.  If you want to stay at 3.5 then I thought you were all set using VS2008.

Grant

[Justin_E]

Marco,

You should only need to add that property to the .csproj files that use DAQmx.

Ralf,

I noticed you were using DAQmx 9.0.2 along w/ Visual Studio 2010. We've identified an issue with the internal drivers included with certain older versions of DAQmx that can cause instability/crashes in Visual Studio. Please upgrade your DAQmx driver to version 9.2.1 or later to eliminate the possibility that this older issue is what you're experiencing. DAQmx 9.2.3 is available here. Here's a KB you can reference:

http://digital.ni.com/public.nsf/allkb/00B15287B2EB542C8625772E00706DBF?OpenDocument

If after upgrading and trying the two workarounds I've suggested you still experience the crash, please let us know.

[Justin_E]

FYI, the DAQmx 9.2.3 Run-Time Engine has been placed on Drivers & Updates, here:

http://joule.ni.com/nidu/cds/view/p/id/2281/lang/en

[lorenzpurple]

Hello

This problem is creating a real economical damage to our business/work.

Here is the situation, on our two development stations :

Windows 7 32 bit (first one) and Windows 7 64 bit (second one)

Visual Studio 2010 Professional (both)

NiDaqMx 9.0.2 (first one) and NiDaqMx 9.2.3 (second one)

.Net 4 (both)

No Labview application, just DAQ devices, and DLL referenced in our projects

Once every two or one day, in a complete casual way, Visual Studio 2010 gets corrupted,

and the only way is the reinstallation of the complete IDE.

While running the first time, everything seems ok, then we get something like

"operation could not be completed" message, or other similar messeges,

after that we close and restart visual studio, and we get only this message :

"""

Error Message:

  C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe

The application has failed to start because its side-by-side configuration is incorrect.  Please see the application event log or use the command-line sxstrace.exe tool for more details.

"""

here is a complete thread of our problem, where you can see other people in trouble :

http://social.msdn.microsoft.com/Forums/eu/vssetup/thread/64aae6a0-c70c-46b3-bfe3-6b9078153158

here is the final SXS trace extract :

"""""

The niPXIe plug-in caused an exception in the CmxsCfgResourceExpert::SynchronizeToConfiguration function in the nimxs process.
See these files for details:
C:\ProgramData\National Instruments\MAX\Logs\20110121_122904-nimxs-0000066C.log
C:\ProgramData\National Instruments\MAX\Logs\20110121_122904-nimxs-0000066C.dmp

Context where exception was caught:
Func: CmxsCfgResourceExpert::SynchronizeToConfiguration Args: plugin=niPXIe configuration=0271B2D0 pass=0 reason=1 userDataSize=0 userData=00000000

"""""

We get BSOD and NIPALK referenced, sometimes NIPALU, and so on...

This complete mess-up happens just every time we work on NIDAQ involved projects,

it just never happens with other much more complex projects in VS2010 / .NET 4

with differente libraries.

I also have some minidumps of the problem,like this :

Problem signature:
  Problem Event Name:    BlueScreen
  OS Version:    6.1.7600.2.0.0.256.48
  Locale ID:    1040

Additional information about the problem:
  BCCode:    76
  BCP1:    0000000000000000
  BCP2:    FFFFFA800C667B30
  BCP3:    0000000000000051
  BCP4:    0000000000000000
  OS Version:    6_1_7600
  Service Pack:    0_0
  Product:    256_1

Could the minidumps be useful ?

This is the 10th time I personally reinstall Visual Studio 2010 in about 2 weeks.

We must find a solution to this problems.

Please Help asap.