BUG: LabView 2009 WebServer crash

Here is a simple VI containing no controls, functions or libraries in LabView 2009 f3.
WebServer
settings are default. After Tools->Web Publishing Tool operation
from other PC we are connecting to this panel (IE6 for example) and
putting a finger to F5-button not raising it.
Web page with the VI is refreshing continiously.
There are 3 results.
1. In DevEnv: LabView die.
2. In DevEnv: Need to restart LabView so WebServer reloads and connection restores.
3. In App.exe: die
4. In App.exe: LabView interpreter loose some while-cycles in case they exist but connection stored.
5. In App.exe: connection lost but the application working good.

Link to original post
Justin Parker
National Instruments
Product Support Engineer

Similar Messages

  • Bug (LabVIEW 2011 sp1 crash)

    Bug (LabVIEW 2011 sp1 crash)
    1) Open LabVIEW
    2) Blank VI
    3) Front Panel / View / Class Browser
    follow exactly this :
    Class Browser / Object library ---> select "LabVIEW Classes" ---> and then clic "Search"
    result : The window "Class Browser Search" opens ----> do nothing ... just "Cancel"
    back to the window Class Browser ...
    Class Browser / Object library ----> now select "DAQmx"
    result : in the window Class Browser : Objet library = DAQmx
                                           Class         = DAQmx buffer
    don't touch anything else (!)
    and now clic "Search" ... LV CRASH

    When you meet your colleagues, could you ask them, of course when they have time, to create this number.
    This will make me happy,  and this would be a small reward      for this bug report.
    Thank you very much in advance ThiCop

  • Labview 2009 SP1 crashes when moving large selection with arrow key

    If I select a lot (10 or 15) of Block Diagram components and try to move them some distance with the arrow key, I will frequently get a program crash.  Since a smaller number of components seems to crash after a longer travel distance, it looks like some kind of buffer overflow error.  I do not see this problem when using the mouse to move selections.
    I have checked to be sure I have the latest video driver for my NVIDIA Quatro FX570.  I have also tried working with no hardware acceleration and no combined writes.  This is happening on Windows XP SP3 with all the current updates.
    It has become so bad that I have to do a Save As every fifteen minutes to keep from losing data.
    Why don't I use my mouse for all movements?  Because it is not as accurate and not so easy to restrict to one dimension of movement.   My hand is not as steady as it once was.
    I hoping someone will have a suggestion that will clear up this problem.
    Solved!
    Go to Solution.

    As I indicated, I had the same problem with 8.5 and just DID a new installation of Labview 2009.
    Since it is possible my three-monitor setup, which obviously requires more video memory, may be at the root of the problem, I am satisfied with the workaround of dragging the objects near their final destination and then using the arrow keys.  
    Three monitors are ideal for front panel, block diagram and Help/Internet/Probe Window.  When I had to work in the field with only one monitor, I felt severely handicapped.
    You may consider the matter closed.
    Thanks for attempting to duplicate the failure.

  • BUG: LabVIEW 8.6 crashes when you save a class vi with the same name

    I am running into an annoying crash.  If you try to add a VI with the same name to an existing class, LabVIEW will notify you that you made an error.  Once you hit OK, LabVIEW crashes.  Obviously, the workaround is not to save any VI with the same name as an existing VI to your class.

    I have attached a ZIP file with an example project.  Open the project and open one of the VIs in Test Class.  Choose File->Save As.  Choose Copy->Open additional copy.  Make sure the box for Add copy to Test Class.lvclass is checked.
    Do NOT try to save the VI over top of the existing VI.   Go to a new folder and save the VI without changing the name.  LabVIEW will save the VI, then inidcate it cannot add the file due to a naming conflict.  Once you hit OK, LabVIEW may or may not hang for a few seconds, then crash.
    When LabVIEW restarts, it does not indicate anything happened. It just comes up with the standard startup screen.
    I stumbled across this attempting to create a copy of an existing VI, but forgetting to change the name.
    I confirmed this does not happen in LabVIEW 8.5.1, so the behavior is new to 8.6.
    Message Edited by Matthew Kelton on 12-19-2008 07:52 AM
    Attachments:
    Class Test.zip ‏19 KB

  • Partial clean up needs wires (BUG LabVIEW 2009)

    The new partial clean up feature of LabVIEW has a little glitch, it needs a wire to be selected to actually perform a clean up.
    For isntance the following VI:
    Where I have selected the top and bottom primitives, when I hit the LabVIEW clean up button, the selection will not be cleaned up.
    Ton
    Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
    Nederlandse LabVIEW user groep www.lvug.nl
    My LabVIEW Ideas
    LabVIEW, programming like it should be!

    altenbach wrote:
    Looks pretty clean to me. What do you expect it to do?
    I expect LabVIEW to align the code.
    I don't have LabVIEW currently active, but if you add a wire between two of the nodes but not select the wire the clean up will be a no-op as well.
    Only with a wire selection it will actually clean up. 
    TST:
    I have seen no difference between the toolbar button and the 'cleanup' invoke node.
    Ton
    Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
    Nederlandse LabVIEW user groep www.lvug.nl
    My LabVIEW Ideas
    LabVIEW, programming like it should be!

  • LabVIEW 2009 crashes at startup with the presence of a certain CRT version on the system

    When installing our LabVIEW integration package on a system running
    LabVIEW 2009 LabVIEW will crash at startup afterwards. Using 'dependency
    walker' reveals, that 'nicont.dll' causes this crash because of a
    side-by-side configuration problem. After some debugging I found out
    that on this particular system installing a certain version of the
    Microsoft CRT will stop LabVIEW from functioning. My fix now is to
    recompile our code with a newer version of VS. I now ship a VS9 version
    of the runtime and everything is working as expected.
    However
    I guess the real problem lies within the LabVIEW installer. I guess a
    needed version of the CRT is not installed by LabVIEW. It still works
    because due to some policy files on the machine it gots defaulted to a
    compatible version at startup. However when I install the following 2
    merge modules on the target system LabVIEW does no longer work:
    Microsoft_VC80_CRT_x86.msm (file version inside: 8.0.50727.762)
    policy_8_0_Microsoft_VC80_CRT_x86.msm (file version inside: 8.0.50727.4053)
    Renaming
    the *.policy file in the SxS dir on the target system gets LabVIEW back
    to run, but of course other SW needing this file does not run then
    I was using XP, 32 bit SP 3
    I can provide additional information if needed. Is this a known problem? Is there a fixed version of LabVIEW already?
    Message Edited by anotherStefan on 02-05-2010 05:44 AM

    Sure! I tried to attach the installer causing the problem to this message.
    However I failed miserably(BAD GATEWAY from the upstream server). Where can I upload the installer to or what do I need to do?
    It will install some other stuff as well (A bunch of VIs, a DLL and an
    OCX(this needs the CRT I have trouble with)and the CRT and MFC runtimes I
    mentioned. An updated version of the installer can be obtain here(however it does no longer show the issue):
    http://www.matrix-vision.com/functions/count.php?url=products/hardware/family/SC/mvBlueFOX/LabVIEW_a...
    The only difference between the two packages is, that the OCX in the
    attached file has been build using VS2005SP1 and in the package the link
    points to I did use VS2008. Apart from that I changed the 2 merge
    modules from Microsoft (CRT and MFC)

  • Crash deploying library after uninstalling LabVIEW 2009

    I have been running LabVIEW 8.6 with the DSC module. Recently I briefly installed LabVIEW 2009 for evaluation, then uninstalled it. Now version 8.6 crashes every time I deploy a library. I have tried repairing, uninstalling and re-installing 8.6 with no success. The crash message says the problem is in msvcr71.dll. There are many copies of various versions of msvcr*.dll all over my computer and I am not sure where the problem lies. Can anyone help?

    Hi Richard,
    Can you please upload a screenshot of the exact error message? I would advise emailing or calling in at National Instruments through this link.
    Ipshita C.
    National Instruments
    Applications Engineer

  • Bug? LabVIEW 2009 Enum in Datalog Refnum Loses Data in LabVIEW 2010+

    Hi 
    Can I please get support from an AE?
    Attached is a LabVIEW 2009 VI with a Control of an Enum in a Datalog Refnum.
    Whereby the Enum's FP Object is represented as an image.
    In LabVIEW 2009 this works fine however, in any higher version (I have definitely tested with LabVIEW 2011, but have been told LabVIEW 2010 is the same) the image is blank.
    Is this a bug - is data being lost?
    Interestingly enough, if I remove the LabVIEW 2009 Enum from the Datalog Refnum then load in LabVIEW 2011 this image displays correctly.
    Is there anything I can do (setting? etc...) in LabVIEW 2009 that will correct this problem so it displays correctly in later versions?
    This issue originated in this LAVA thread.
    Cheers
    -JG
    Certified LabVIEW Architect * LabVIEW Champion
    Attachments:
    Datalog Refnum Enum_LV2009.vi ‏10 KB

    This was reported to R&D (# 311354) for further investigation. 
    As a possible workaround, if you move the enum control out of the datalog refnum before saving in LV 2009, when you open your VI in LV 2011 the image will still show up for the enum control. You can then move the enum control back into the datalog refnum and it should work fine. 
    Thanks for the feedback,
    Daniel H. 
    Customer Education Product Support Engineer
    National Instruments
    Certified LabVIEW Developer

  • Simple Math VI crashes LabVIEW 2009 SP1

    Hi,
    We previously filed a related issue, (ref #: 7302858). The last problem was resolved by 
    Andy Hertzka from NI re-compiled the VI and send it back to us. That re-compilation solved the LabVIEW crashing.
    However, the interesting crash happens again.
    I attached a working VI before the change and a non working VI after the change and save. All the change I applied to the VI is
    1. Add the "Word bits" as a connector on the diagram
    2. Save it Then the VI begin to crash LabVIEW 2009 SP1.
    Before the change, the VI was functioning all right.
    Any idea why this might be happening? Can you try to recompile the non_working version and send it back to me for a try?
    Thanks,
    Tian
    Attachments:
    Non_working_AfterChange_RECOMPILED LRSample_U32in_U32output.vi ‏110 KB
    Working_B4Change_RECOMPILED LRSample_U32in_U32output.vi ‏110 KB

    Tian,
    Like Andy I was unable to see why this code is unstable on your machine. I am able to run the code fine on my computer without any problems. Looking at the code on the block diagram I do not see any major "crash worthy" issues with it. 
    I have resaved the VIs like Andy had in order to fix your issue. By the way what OS are you using, windows 7? It might be helpful to save the log file for the LabVIEW crash. You should get this option when LabVIEW is restarted. 
    <Joel Khan | Applications Engineering | National Instruments | Rice University BSEE> 
    Attachments:
    Non_working_AfterChange_RECOMPILED LRSample_U32in_U32output1.vi ‏108 KB
    Working_B4Change_RECOMPILED LRSample_U32in_U32output1.vi ‏108 KB

  • LabVIEW 2009 Crash when save for previous

    I'm having a problem when trying to save a VI in LabVIEW 2009 to a previous version of LabVIEW, in this case 8.2, but itseems to crash no matter what version I choose.  I've narrowed the problem down to this:
    If the vi contains an event structure I get the following error: Fatal Internal Error: "MemoryManager.cpp", line 547
    If I remove the event structure it saves fine.  I'll even get the error if I create a blank vi, and drop an empty event structure on the diagram.  No controls, no other code.
    Is this a known problem?  Is this a problem with my copy of LV?  Is there a workaround?  Removing the event structure in this application is not an option.
    Thanks
    Rob
    Message Edited by rgough on 09-30-2009 03:58 PM
    Solved!
    Go to Solution.

    Hi sk_LabVIEW,
    Currently there is no workaround, but fixes are being worked on. Sorry.
    Flash
    National Instruments
    Applications Engineer

  • My compiled program crashes after first run (LabVIEW 2009)

    I have a compiled program created with LabVIEW 2009 that on the first run after the computer is re-booted will work fine but after shutting down the program it will not run properly. 
    The program uses a compiled launcher to dynamically activate a set of VI's containing Queue Driven State Machines (QDSM).  On subsequent program starts the launcher module comes up fine and its progress bar shows that it is launching each of the VI's.  Once the launcher is complete it removes itself from memory leaving the dynamically launched VI's running.  The subsequent launches which fail the main user interface VI pops up barely long enough for the observer to see (if at all) then shuts down.  The program is then gone from memory as far as I can tell.  There are no processes in memory or anything.
    Additionally, the when I try to run the installed version of the exe on a computer that has the 2009 development environment installed I get this behavior consistently with a successful run even once.
    In both cases my program does not throw any errors (which are logged) nor does the runtime engine generate any that I can see.  Also, when I run my program in the development environment the program does not behave this way.  It has no problems at all.
    I have used this style of architecture before in LV8.6 with out any problems.  Can anyone suggest some possible solutions or even some debugging tips?  I have never had a problem that I could not duplicate in the development environment so I am unsure how begin attacking my issue.
    Thanks for any help.
    Jason
    Wire Warrior
    Behold the power of LabVIEW as my army of Roomba minions streaks across the floor!
    Solved!
    Go to Solution.

    I have solved the problem I think (at least as far as testing to this point has revealed).   After I added in the ability to log the states passed to the QDSM's, I was able to determine that the program was "crashing" after I dynamically closed the front panel of the launcher.  My program was designed to close the front panel of the launcher then pop-up the front panel of the main UI.   My EXE is built on to contain the launcher with my other QDSM files being maintained externally in specific directories.  What appeared to be happening is that when the launcher closed its front panel and before the UI opened up the run-time engine would decide since there were no windows open it would close itself down.  This is my supposition about what may be happening any way.  I modified my code to changed the launcher window to hidden and delay for 1/2 a second to give the main UI a chance to start fully running.  This fixed the problem, or at least worked around it.  If someone out there can explain to me exactly what is happening I sure would appreciate it.
    Thanks for all the help those of you who responded.  Your advice was very beneficial and certainly led me to a resolution faster.
    Jason
    Wire Warrior
    Behold the power of LabVIEW as my army of Roomba minions streaks across the floor!

  • LabVIEW Run-Time Crash (2009) lvrt.dll

    Hello,
    I am currently experiencing a problem with an application built with LabVIEW 2009.  At random periods (often not more than once or twice a week when using the application regularly) I get a Windows error referencing lvrt.dll as the culprit.  I am having a hard time troubleshooting because of the scarcity of the problem, as well as the random nature (appearing in completely separate parts of the application, does not seem to be associated with any particular module of the code).
    A little background- I have inherited the application maintenance, which has gone through many different versions of LabVIEW.  I implemented the code into LabVIEW 2009 from 8.6, which is when the error began to appear.  At that time no change was made to the source code itself, just merely built using 2009 rather than 8.6.
    I apologize for the somewhat vague information; unfortunately this is all I have after working on this issue for weeks.  If anyone has any suggestions or similar experience your advice would be greatly appreciated!
    Thanks

    Hello Again Sean, thanks for your help.
    I am running 2009 SP1.
    There are other DLLs called throughout the code, but not any specific calls seem to cause the crash.  Likewise, as the crash will occur randomly throughout all of the software I suspect it is not in the code itself (i.e. this application consists of nearly 1000 VIs.  The crash has occurred while running various parts of the software, so it can't be traced to any particular party of the code via debug mode, highlight execution, etc).
    I have attached a screen shot of the error message I receive.  Any other thoughts would be greatly appreciated.
    Attachments:
    error2.JPG ‏52 KB
    error1.JPG ‏26 KB

  • Potential Bug with LabVIEW 2009, Report Generation Toolkit, and MS Office 2003

    We have discovered an issue with the above listed software.  Specifically this pertains to Print Report.vi in the Report Gen palette.  Basically, we have discovered that with Office 2003 installed the VI will error out.  We've been using it in an executable, and the executable physically fails (and asks us to report an error to Microsoft).  With Office 2007 we don't have a problem.  We've tried building the examples into executables, and those work because they are printing HTML reports.
    Also, we have converted back to LabVIEW 8.6 and rebuilt the executable and installed and it works perfectly.  Its on the combination of LabVIEW 2009 and Office 2003 that seems to fail.

    yeah, we had seen that, and been told about it by another user.  we tried, to no avail.  we still have ended up having to migrate back to 8.6.1 to get the executable to run properly.

  • LabVIEW 2009 sp1 not responding / crash

    Hi, 
        I seem to have developed an issue with LabVIEW whereby it freezes at a random point during execution. It is not a case of a VI freezing, rather the LabVIEW application itself ceases to work and needs to closed by task manager. What I have running at the time is a host VI that sends and receives data over a TCP connection to a real-time target on a PXI. The real-time application keeps running after the crash. The host system is also running 3D picture control showing some basic graphics. The whole system is controlled at a top level by a program written in C#  over a TCP connection but can run stand alone. When running stand alone the problem does not occur.
       The communication between the C# and LabVIEW works fine, yet at a random point during operation, LabVIEW freezes while the C# continues to work. This doesn't seem to correspond to a particular action by the C# program. I guess my question is, is there any likely culprit by which LabVIEW can be crashed by an exernal program where the only communication is via TCP that seems to work fine and where there doesn't appear to be excessive memory or CPU usage?
    Cheers. 
    Solved!
    Go to Solution.

    Having further investigated it appears to only occur as TCP exchange is taking place and the full LabVIEW application doesn't appear to have crashed, but several VIs hang and can't be closed. There are three total TCP connections running, one that links to the PXI unit, one to the C# application and one from the C# to the visual display VI that is idle when this event occurs. Does anyone know of any reason why a TCP connection can cause LabVIEW to hang? The same connection has worked numerous times before the error occurs. Appears to only happen when the 3D picture control is running.

  • How can I diagnose a Labview RT program crash on cRIO 9073?

    I have 2 cRIO 9073 purchased about 1 year apart.  Both are running the same realtime application.  The first cRIO runs fine.  The 2nd cRIO crashes intermittently while executing 1 particular VI that contains 2 timed loops running in parallel (1 collecting data and the other controlling machine movement).  When it crashes, the app stops, web server and FTP stop responding, MAX cannot communicate with the device ( I must perform a hard reset).  After reset, viewing the error log using MAX shows no errors.  I've added message logging to see if it stops in a particular place, but see no patterns.  In some cases, the device seems to be continually restarting (every 2-3 minutes) until it finally hangs.  In many instances, my configurations files (used to store runtime variables) have been corrupted or erased.  When trying to deploy the app on this Rio, I generally must try multiple times because I receive the error, "Error deploying on target".  I have tried formatting the flash and reinstalling the OS many times from different sources.
    I'm running Labview 2009, SP1 with the FPGA option. 
    Any ideas on how to diagnose this problem?  Are there any diagnostic tools to test this device?

    Here's a better description of what I'm trying to do.  This system is used to control the head position on a test machine.  I used the LV RT wizard to create the base VI with 1 deterministic loop and 1 non-deterministic.  The deterministic loop schedules 2 different test.  Test 1 is every 5 minutes (collect analog data, read temperatures, calculate new head position based on temperature , drive stepper motors to new position, collect data after moving, then dismiss).  Test 2 runs once a day with a duration of about 4.5 hours (drive stepper motors to user defined position, simulatiously collect data at various rates from 5Hz to .01 Hz, drive head to next user defined position, etc). This test has 2 timed loops running at different rates, one collects data, the other moves the head and acts as a timer to know when to move to the next position.
    If I never run test 2, then the system has never crashed, leading me to believe the problem is in the test 2 VI.  The crashes don't necessarly occur in the Test 2 VI.  On some occations 1-2 hours after Test 2 has completed, the CRIO will start rebooting itself (every 2-3 minutes).  This may happen 4-5 times until it will finally hang completely. 
    Since the crashes happen randomly (it may run for 2-3 days before crashing) I'm trying to find some way of trapping  errors or exceptions that would give me some clue as to what the problem may be. 

Maybe you are looking for