I'm trying to run Inspector from the command line. I have it working fine inside Visual Studio. I click on "Command Line...", copy the command to the clipboard, and run it exactly as is.
I get an error that says "There is no disk in the drive. Please insert a disk into drive \Device\Harddisk3\DR3."
Can anybody help me resolve this issue?
Here's my batch command line exactly as copied from the clipboard:
inspxe-cl -collect mi1 -knob detect-leaks-on-exit=true -knob detect-resource-leaks=true -knob enable-memory-growth-detection=false -knob enable-on-demand-leak-detection=false -knob still-allocated-memory=true -knob stack-depth=8 -mrte-mode=auto -module-filter-mode=include -app-working-dir T:\ -- C:\exam.exe
I don't know why working-directory is "T:\". Was it possible there was no driver mapped in your command prompt environment? But I saw your program worked from c:\exam.exe:
I suggest that you try: (some options are default "on/off", if you really want them - append)
inspxe-cl -collect mi1 -app-working-dir C:\temp -- C:\exam.exe
I tried your suggestion but it didn't work. I still get the same message popping up. It pops up not just once, but several times.
The annoying thing is that this is enough to prevent me from running Inspector in batch mode: for every job I have to wait for this popup to appear - it appears several times - and I need to cancel each of them individually.
The goal was to use Inspector as part of our QA procedure but if it cannot be used in batch mode this is out of the question. It makes the tool of limited use only, unfortunately.
When does the dialog appear - right away, or while the target program runs, or during the processing (symbol resolution, etc) that Inspector does afterwards?
What directory are you running the command in? Result directories ('r000mi1', 'r001mi1', etc.) will be created in the current directory.
One other thing to try would be to move the target application away from the root of the drive and into a subdirectory (C:\temp\exam.exe)
The dialog box appears while the target program runs.
I'm running the command from C:\users\user\Inspector. Result directories are being properly created here:
10/03/2014 11:51 AM <DIR> r000mi3
10/03/2014 12:55 PM <DIR> r001mi1
10/03/2014 12:58 PM <DIR> r002mi1
10/03/2014 01:07 PM <DIR> r003mi1
10/03/2014 01:23 PM <DIR> r004mi1
10/03/2014 01:25 PM <DIR> r005mi1
10/03/2014 01:30 PM <DIR> r006mi1
10/07/2014 08:47 AM <DIR> r007mi3
10/07/2014 08:57 AM <DIR> r008mi3
10/07/2014 09:09 AM <DIR> r009mi3
10/07/2014 09:21 AM <DIR> r010mi3
10/07/2014 09:45 AM <DIR> r011mi3
10/07/2014 09:52 AM <DIR> r012mi3
I already moved the target application to C:\users\user\vs\x64\Debug\exam.exe. "vs" is my Visual Studio workspace. So I'm running directly from where Visual Studio creates the application since I know I can run Inspector from within Visual Studio with no problems.
I discovered one more thing. I added a "-v" to the options to see whether I could get some more information. This is what I find:
Unloaded module: C:\Windows\system32\VCOMP100.DLL
Unloaded module: C:\Windows\system32\UxTheme.dll
Unloaded module: C:\Windows\system32\MFC100ENU.DLL
Completed analysis for C:\Users\user\vs\x64\Debug\exam.exe
Application exit code: 0
Result file: c:\Users\muller\Inspector\r013mi3\r013mi3.inspxe
After the last message, the popup appears - about 5 or 6 times.
Could you try running with '-no-auto-finalize'? My current guess is that the symbol resolution step is attempting to access the drive during its search. This flag will prevent that step from running.
It worked! The only issue is that after clicking on "Cancel" on the popup the previous time I also got these additional lines:
21 new problem(s) found
1 Invalid partial memory access problem(s) detected
13 Kernel resource leak problem(s) detected
1 Memory not deallocated problem(s) detected
6 Uninitialized memory access problem(s) detected
Now I don't get these lines anymore. But I suppose I can still find these problems if I look at the files in r014mi3. Since I'll be running Inspector in batch mode I need to add some searches to my script so I can find all the uninitialized memory reads, all memory leaks, and all invalid memory accesses - along with the stack dump, like I normally see on Visual Studio.
The -no-auto-finalize switch also shuts off reporting. You can use 'inspxe-cl -report summary' to get that information. If run on a non-finalized directory, if will first perform that step, which will very likely yield the pop-up dialogs again.
When running under Visual Studio, the directories to search for binaries and debug files are taken from the VS project. On the command line, you might need to specify them with the -search-dir option.
The _NT_SYMBOL_PATH environment variable will also be used for symbol paths to search.
This is great. Thanks for the help. I managed to use Inspector in batch mode to generate data for many runs.
For a typical run, I get the following files/directories:
Where do I go to find uninitialized memory reads, memory leaks, invalid memory accesses, etc? Maybe this belongs on another thread...
The file with the data has a .pdr suffix in the data.0 directory (exam1_118428.pdr). You can look through it and figure out the format.
However, it would probably be more useful to find the cause for the dialog, so you can use the results with resolved symbols.
There's some discussion at this link about the 'no disk in drive' error, and how to find which drive/drive letter is being referenced: http://www.sleeter.com/blog/2013/08/fixing-the-there-is-no-disk-in-the-drive-error/ .
I suspect that some binary is referencing a PDB file on the missing drive. However, Inspector should handle this case w/o putting up a dialog, so something more is going on.
There is a reference to a PDB file compiled into an executable or DLL. Running 'dumpbin /headers' will show the compiled-in value. Running 'dumpbin /pdbpath:verbose' will show which PDB file (if any) is actually found.
The PDB references compiled in to your project should be already be present (unless some post-build step moves them around). PDB references in system DLL's contain just the name, and no path, and shouldn't be a problem. The place to look is at 3rd party DLL's, or dependent projects that were compiled elsewhere. Use dumpbin to see if there are any references for the PDB file to the offending drive letter.
If I double click on the pdr file I do get the information I want. But this is no way to run Inspector in batch mode :-).
I do use lots of external libraries. Maybe the thing for me to do is to remove them all - using a simple test program that doesn't really need any of them - then slowly introduce them one by one.
Very good communications!
But it could be an issue - if symbol resolving not found, it should report warning message. If you use "-module-filter-mode=include -module-filter= module-name" could avoid this error I think, because finalizing will not check symbol location of run-time libraries or 3rd-party libraries.