Most GPF's are caused by making reference to pointers that are no longer valid or not owned by the calling process, which may or may not bear some resemblance to your problem of not being able to view a Global.
Since the GPF has occurred, the Debugger may have already released references to your variables, hence it is not active any more.
For example:
1. Load an external module (say TCP / IP or similar)
2. a = Ptr to some external function within that external module.
3. Use the function pointed to by a.
4. Release the external module.
5. Use the function pointed to by a.
Step 5 will cause the GPF since it will be trying to access memory outside of the scope of your application. The module that was loaded existed within its own memory space, and 'a' merely contained a reference to it. Since the GPF has occurred, you cannot see what 'a' contains, since it is no longer active (halted by the GPF).
Now, it may not be apparent straight away by looking at the GPF, and it may or may not be related to an external module.
I used TCP as an example, since it is pretty easy to simulate the same fault as you are showing. For example, if I open a TCP session, CVI will use an external library call (one of the Windows DLL's), to handle the TCP calls at a lower level. One of the functions allows me to register a callback function within my code, which gets called by the windows DLL upon certain conditions (such as data ready?). If I close my code without telling the external process, or my code terminates abnormally for some reason, when the trigger event occurs that will call the registered callback function, it will cause a GPF within that module, since it will be accessing memory not valid anymore.
There are many what seem harmless function calls within CVI that will cause an external module to be loaded, (such as VISA, or GPIB, or TCP). Race conditions can occur during the loading unloading of these, which can also create GPF�s.
Also, just a plain old bad memory reference ptr can cause the same.
Ptr = malloc (lots of space)
Causes a ptr to memory within the memory space of the executable that created it, or, it belongs to the executable (controlled by windows).
Setting Ptr = NULL, and using that Ptr will in some cases be trapped and return a known error. But bad ptr arithmetic for example, will still be a valid reference in terms of memory, but could cause GPF�s if that memory is protected or not owned by the process that tried to access it�
There are tools around that will allow you to see what process is using what memory areas. So when the GPF occurs, you can see what process was using that memory location. You can then verify whether its within your code, or in an external module (called previously by your code).
This is a question I should have asked before typing the above, but what sort of GPF is it ? And what error message do you get?
So basically, its either a bad ptr or a bad function call, and those are where I would look first.
I will have a look for the names of those debug applications if that will be of any help to you.
Regards
Chris
