Sparkette Posted June 27, 2012 Report Share Posted June 27, 2012 Every time LabVIEW crashes for me, it gives me several disk errors beforehand. Each of these has "Cancel", "Try Again", and "Continue" as buttons. I've always just clicked Continue, so I'm not sure about what happens if you click a different one. Here's the sequence of errors: (not sure if it's the same every time) There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR3.There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR2. There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR2. There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR2. There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR3. There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR3. There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR3. There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR3. There is no disk in the drive. Please insert a disk into drive \Device\Harddisk2\DR3. I do have a RAID setup, so that may have something to do with it. It's just annoying, sort of adding insult to injury whenever LV crashes, which unfortunately isn't as seldom as I'd hope. Quote Link to comment
Saverio Posted June 27, 2012 Report Share Posted June 27, 2012 I don't think your problem has anything to do with LabVIEW. I'd check your system if I were you. Quote Link to comment
asbo Posted June 27, 2012 Report Share Posted June 27, 2012 There have been a couple other posts on this by ShaunR and Daklu - primary speculation is either disk corruption (by me, no shame) and antivirus/etc locking the disk. Quote Link to comment
GregR Posted June 30, 2012 Report Share Posted June 30, 2012 There is another possible answer. When we build the EXE and all the DLLs that make up LabVIEW, we do generate symbol files. We don't ship them but we hold on to them for debugging. Each executable remembers the absolute path that this symbol file was created at on our build machines. In many cases our build machines are setup with multiple drive letters rather than just one huge C drive. When NIER encounters a crash, it uses a MS DLL to look for the symbol files to try to put more details in its log. One of the places this DLL looks is the path in the executable. I think this behavior is frequently the result of accesses to drive letters that are not mapped or mapped to removable media. The exact behavior may depend on what the drive is. I know we have had cases where it would request you insert a disk into an optical drive. In the end there are no ill effects. This is just a matter of unfortunate error handling. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.