Unable to interrupt Igor process after some time

What version of Igor are you using?

I'm not sure what you mean by, "Igor small, black and white cross loading icon"? Is that the spinning black and white beachball mouse cursor?

Is the Abort button in the Igor frame present?

I am using Igor Pro 8.0.3.3

Yes, I mean the spinning B/W beachball cursor.

When it gets to the state that it cannot respond to abort, basically it is such that running the routine (involving the XOPs) will put the program in a fake "frozen" state. Windows treats it as not responding, but in fact the acquisition and the processing is running. It will quit that "frozen" state once the actual work is done.

Your description sounds like what happens when some computation involves a long-running tight loop that runs for a long time. I don't know why that would happen only after running for a while. Do you accumulate many waves with time? What does your XOP do? Is it possible that over time it has more and more to do? That could conceivably result in the symptoms you describe.

Thanks for the comments, I agree that the cause can be hard to find. The XOP involves transferring data (up to GBs) from the digitizer, and to and fro the GPU. I believe somewhere in between could have a bug but I have yet been able to narrow it down. So I was wondering if Igor had any mechanism to debug this, or help check which part of the process went wrong.

You could use UIforETW (https://github.com/google/UIforETW) to collect sampling data for Igor and then analyze the traces in WPA. See https://randomascii.wordpress.com/2015/04/14/uiforetw-windows-performance-made-easier/ for a guide to getting started doing this.

Since we don't publish Igor's symbols you won't be able to see the names of our functions in your stack traces, but if you configure your XOP to generate debugging symbols (.pdb files), which can be done even for release builds, then you should be able to see symbols for your XOP. If you look at where most of the time is being spent, that should give you some idea of whether it's spent in your XOP or in Igor itself.

If you get really advanced (and are using Windows 10), you can use the Windows trace logging API (https://docs.microsoft.com/en-us/windows/win32/tracelogging/traceloggin…) in conjunction with UIforETW in your XOP and emit events as a trace logging provider. You can use UIforETW to record these events as well as described at https://github.com/google/UIforETW/issues/84#issuecomment-274741685. See https://github.com/tpn/winsdk-10/blob/master/Include/10.0.14393.0/shared/TraceLoggingActivity.h for some trace logging examples.

Igor can't look inside your XOP to provide debugging info, but you should be able to use Visual Studio's debugging facilities. The XOP Toolkit manual includes information about how to use a symbolic debugger in Visual Studio or Xcode to debug your XOP. It also has a chapter about debugging in general. When Igor appears hung, you may be able to get some information about where it is executing using the Task Manager to create a minidump of the executing process. In the Task Manager's process list, right-click on Igor and select Create Dump File. You should be able to view the dump file in Visual Studio. Since you don't have Igor's pdb file, you can't see Igor's symbols, but I think you should be able to see your XOP's symbols.

Trasferring GBytes of data from one place in memory to another can take a long time. If you do it in a tight loop, Igor will appear hung while it is in progress.

Have a look at https://github.com/byte-physics/matrixfilereader/blob/63dd868556c60df9a….

This is C++03 code using boost threads. It uses a separate thread for preforming a long running operation and uses SpinProcess() to signal to the user that something is in progress.