Well,
(Keeping an eye on my flak jacket)...
If all of these assumptions are true:
-you want to--or have to--stay out of the CVI debugger
-you don't have to automate this (and don't mind putting pencil and paper to it)
-you have a valid MAP file for the executable, from whatever compiler made the EXE/DLL
-you run an NT descendant (2K, XP, 2K3, etc.) on Intel silicon
Then you can use tools similar to Microsoft's WinDbg to reverse engineer some of this. The address of the parent function that called your target function may be sitting in EBX the moment your target function first starts to run. I know this to be true in certain situations, but I can't definitively say what situations might make it false. Maybe not with hyperthreaded CPUs. You should be able to single-step through WinDbg and watch as any nested function calls return. I would rather go to the dentist than do that all day. You would probably need a good reference book for WinDbg too, because it is faily un-intuitive.
You can find all of what you want through the CVI debugger, even across multiple threads, if you debug it live. If you have the source code, can't you feed yourself hints about the program flow and timing by adding messages to the CVI debug output window (like stdout)? What about doing the same with a text file or a database? I don't know of anything native to CVI that will help you get the parent functions in an automated (programmatic) fashion. I've heard that C++/NET can do it, since they have stack dumping functions....
Orlan