Hi Frank,

>No symbols are loaded for any call stack frame.

Symbols can be loaded from the Microsoft web site or the Microsoft symbol server. For occasional debugging that's overkill, though.

> The source code cannot be displayed.

The source code is usually only displayed when the crash happened in the MSVCRT runtime. In most other cases you need to inspect assembler code: Debug > Windows > Disassembly.

>I don't know what else to do.

The first thing every VFP developer can do is checking the module. Open the module window (Debug > Windows > Modules). You get a list of all DLLs that were loaded at the time of crash.

First sort the list by Address (you might have to scroll to the right). Then search for the DLL that is located at the adress where the crash occurred. Frequently the crash didn't happen in VFP's code, but in a third party addon such as a remoting software, virus scanner, printer driver, etc.

If that doesn't help, scan the list of DLLs. You get the name and the version of all files. Look for trouble-making DLLs and ask the user to turn them temporarily off. Check if you users is using outdated versions, or if there are known problems with these DLLs.

You also have the full path of DLLs and your EXE. If you know that some path names cause problems in your application, or if you think the user launched the wrong executable, you can see this, as well, in the list.

Next check if you can deduct from the data what the current operation was. Open the registers window (Debug Windows Registers) and a memory window (Debug > Windows > Memory > Memory 1). Arrange them side by side. Then type the name of each register (EAX, EBX, etc) in the address combo of the memory window and press enter. Scroll up a little.

Sometimes the call stack helps too. Open the call stack window (Debug > Windows > Callstack) and the thread window (Debug > Windows > Threads). The call stack window displays the call stack of the current thread. Double click each thread to see where they were at the time of the crash.