Well, first, don't combine the 'project' and 'activity' commands to vtl. :smileysad: This probably shouldn't even be allowed and you may have identified a bug, but it is definitely not safe to do it.
Instead, as I said in the other post, use the 'vtl activity' to collect the data and then 'vtl pack' to export the data. Then, in vtlec, use the File -> Import menu item to load the data.
Since sampling is a system-wide data collection mechanism, you will always be able to see all the processes running during the collection. Sometimes users what to see this info (e.g., inter-process communication, driver developers, etc.). To limit your view, specify your default view to open for Sampling as Processes in the Preferences (See Window menu, then expand VTune Performance Analyzer and select Sampling). Now, when the results are opened, select your process and press the Threads (if your app is multi-threaded, for example)or Modules buttons, or double-click to open the Threads view.
Sounds like you're running out of system resources of some kind (processes, filesystem space, something...) when running a bigger application on vtlec.
If you view the "real" application using the vtl command, does it lock up too?
To test, try these:
$ vtl view | more
$ vtl view -gui
If one or both of these don't fail, at least you'll have a workaround for now.
Note that the -moi flag is not a guarantee that you will see the module you requested when you run sampling: for example, what if the module doesn't even run? The -moi has a more solid meaning with the callgraph way of operating. To learn more about this:
$ man sampling
$ man callgraph
In the command line example that you list below, it might make more sense to use various vtl view commands where you list the -mn (module name) for the modules you are looking at. The "man sampling" command will give you more on that, with the "view" options of vtl.