When I am using vtune to collect information of a process I only need to focus on the result of one particular dll(lets say X.dll). But When I finished with running the process and in the collecting information stage, one dll(lets say Y.dll) will stuck with retrieving information forever.
I only have symbols for X.dll
I don`t have symbols for Y.dll
Is there a problem with symbol server settings ?.
I`m using Visual Studio 2008 and Win7 32bit.
Related
I'm running VTune on Linux and collecting results fine. I'm able to open the VTune gui over X and see the results correctly. However, it's slow -- so I'm trying to view the results using my VTune for OSX client. My understanding from the docs is that this is possible. However, while I'm able to see summary stats such as how long the program took to run, how many threads it had, etc., I'm not able to see symbols from the source, and the Bottom-Up tab is completely empty. I think this is due to the fact that VTune is looking for source code and debug info at a path that doesn't exist on my mac (but does on my linux machine). I'm simply copying over the entire output directory from VTune, which includes the amplxe file, and archive, config, data.0, log, and sqlite-db directories.
What is the recommended way to view VTune output data on the OSX client?
If VTune result was finalized on the target system, it can be viewed on any other system, e.g. on OSX - you need to copy entire result directory and open it in VTune. Symbol files are needed during the finalization process only. Source files - when you attempt to drill down to source view.
Empty Bottom-Up looks strange, you should probably submit a bug through VTune support. Before doing this please make sure you're using the most recent VTune version.
Please note also you can collect from the target Linux directly using VTune GUI on OSX via remote connection.
I have a situation where there are two different users using the same machine, debugging the same package. (SQL Server 2012)
When a breakpoint is set in a script task, for the one, when the breakpoint is hit, execution pauses appropriately, and VSS is opened, at the right point in the code, paused, ready to step through.
With the other user, visual studio opens, but the code is not in view. Although the code can be opened, and the breakpoint is visible, the debugger does not appear to be attached and he can't step through.
To be clear, this is the same machine, same project, just two different users, and we're unable to identify any major differences between the two users (both are local admin).
The project settings are for interactive mode = true, 64 bit = false.
Anyone have any idea what could cause this?
I would resolve this issue by not sharing the same source files amongst developers. Each developer would have their own copy of the project, synchronized via source control e.g. TFS, VSS. TFS in particular brings a host of other features and can be used online for free.
I have a project which reads in a text file (approx 2.6 GB in size), aggregates the data at some level and writes out a smaller file.
I've observed that if I run the program from Visual Studio in debug mode, it takes a lot of time to run (about 45 mins).
Instead, if I open a command prompt, move to the Debug folder in my Visual studio Projects folder and run the same exe, it completes in almost 10-15 mins.
I've also observed that the memory consumption is very high when running through Visual Studio.
I'm not stepping through the code, nor do I have any breakpoints in it. Why does Visual studio take so much longer to run the same executable compared to running it directly from cmd?
P.S.
I tried searching for this type of issue here, but most questions are about Visual Studio taking long while stepping through, or taking too long to start execution in debug mode.
I couldn't find anything about why the same executable takes much, much longer while running through Visual studio when everything else is the same.
The major cause of a probgram running much slower inside Visual Studio than outside is because of the Debug Heap which does a lot of error checking.
Try setting the environment variable _NO_DEBUG_HEAP to 1 in the project's settings (Debugger -> Environment) to disable this (see docs).
This should make it run a lot faster, though obviously you're not going to get as much error-checking - caveat emptor.
Think about it, when running inside the debugger, it (VS and debugger) will load the debugging environment, "instrument" and "analyze" the execution and will let you stop, set breakpoints, check and modify values, ...
When just running the DEBUG version, you will not load up all the debugger environment, you will just run the exe.
now, when you will compile your project in RELEASE, them will will be even faster.
I am using Intel(R) VTune(TM) Amplifier XE 2013 Update 5 (build 274450) for my linux application hotspot collect， but the report says the "[Outside any known module]" consume most of the time, so i want to get more info about the unknow module.
when i read the release notes of the vtune Amplifier, it says "List of hotspots may contain "Outside any known module" on systems with kernel older than 2.6.20 (200233501)", but my linux kernel is "2.6.32", any idea about this?
Check that your program is not generating code on the fly (i.e. is not JIT-ing). You may also want to switch grouping to "Module / Code Location / Call stack" and see which virtual addresses cannot be mapped by VTune to any known module.
I have been suffering from this issue in the past as well and it is very frustrating if you don't know why it is happening.
2 weeks ago I installed Ubuntu 13.04 and vtune update 14 and I was jumping from joy because I could see (again) what happened inside my code.
After doing some updates on my Ubuntu, vtune started to show your problem
I installed the kernel sources.. no help..
I reinstalled the driver, no help.
I reinstalled intel vtune.. no help.
And then I decided to run under root, and what do you know.. It works; no more 'Outside any known module'. I switched back to my regular user, it stopped working. I switched back to my root, and it works. So perhaps some kinds of access issue.
Maybe you could try this.
Probably you have some kernel hidden addresses by kptr_restrict, you ca review the value of "/proc/sys/kernel/kptr_restrict":
kptr_restrict = 0, kernel addresses are provided without limitations (recommended).
kptr_restict = 1, addresses are provided if the current user has a CAP_SYSLOG capability.
kptr_restrict = 2, the kernel addresses are hidden regardless of privileges the current user has.
You can use this option before running the trace:
sysctl -w kernel.kptr_restrict=0
More details here: https://software.intel.com/en-us/vtune-help-enabling-linux-kernel-analysis
Hope this helps!
I have been writing and debugging a minifilter on Windows 7 using the IFS Kit for some time now. it finally works, but as I require to add further functionality, I will spend some more days playing with it
what I'm worried about is debugging. until now I have simply built the driver, installed it on a virtual box and tested it by verifying dbg_print statements. I have been using this simple and error prone approach, as I could not find anything about how to debug minifilters more structured and programmatically.
are there any best practice methods to debug minifilters or filters? can visualDDK be used to add (remote) debugging functionality to visual studio for minifilters?
greetings,
curiosity
The Windows DDK includes a copy of windbg which you can use to connect to the VM over a named pipe with the appropriate configuration.
You can do one better by using VirtualKD to get an accelerated channel to talk to the kernel debugger embedded in Windows.
If you want to do debugging using the Visual Studio user interface, you should look at VisualDDK.
Both are powerful tools, but they require a little work to get set up the first time.
I tend to just use WinDBG because it is the easiest thing to set up on random QA machines etc.
But I have used those tools to iterate rapidly during initial development of a project.
Good luck.
Visual Studio does not support debugging in kernel mode. You can use kd or WinDbg, which are both part of the Debugger package included in Windows DDK. This will get you started with debugging:
Configure kernel debugger on VM and attach WinDbg. Instructions are here: http://ndis.com/ndis-debugging/virtual/vmwaresetup.htm.
Build your binaries in debug mode (or in release with full symbols).
Once WinDbg connected, fix up symbols, and source path. Make sure you added location of symbols of your new driver to the symbol path.
Now you can debug similar how you use VS for user mode apps.