Essentially, you are asking how to debug a DLL. OCX is just a DLL file loaded into a process. This is a somewhat broad topic, but I will try to give a quick start:
DLL / EXE / OCX files are commonly referred to as “modules” in the context of Windows programming. All of them are basically the same thing. I will call them DLLs here, though for simplicity.
Debuggers (Visual Studio and Borland are both debuggers and IDEs) “attach” parasites to processes, allowing you to do things like given breakpoints, read process memory, see stack traces, etc. They can see / manipulate all memory and resources for this process, including all DLLs.
DLLs do not contain much information to help debuggers, even in building debugging. They mainly contain binary machine code, and if you enter a DLL call using a debugger, you can only see the assembly code, not the source code. Functions are only addresses in memory, local variables are not even visible; you get only some pointers to the memory stack.
PDB files ("program database") contain all the additional information and metadata for the debugger to do things like map addresses in memory with lines of source code, local variables, data types, function signatures, etc. This information is called "debugging characters" or simply "characters". When Visual Studio creates the DLL, it issues the corresponding PDB file. This is this PDB file, which allows all magic to go through the source code in the debugger, view local variables, properly view data types in the viewer.
When the Visual Studio debugger is connected to the process and sees the loaded DLL, it searches for the corresponding PDB file. He searches for this in several places - the simplest of which is in the same folder as the DLL. Therefore, if you downloaded C:\something\myctl.ocx , it will look for C:\something\myctl.pdb . If he can find it, he will use it, and you can debug the DLL with rich debugger support. If he cannot find it, you will be where you are now - where DLL calls are a black box that you cannot see.
Microsoft even provides PDB files for the Windows DLL, such as ntdll.dll . They should be downloaded as needed. Visual Studio can do this automatically by going to Tools -> Options -> Debugging -> Symbols , and it should be possible to use Microsoft Symbol Servers to automatically retrieve missing symbol files.
A small example to put you in the right direction:
Say you wrote an OCX called myctl.ocx , which crashes when it is added to a Wordpad document. The way to debug is to attach the debugger to wordpad.exe . In Visual Studio, that Debug -> Attach to Process , I find. When it is attached, you can even see in the output window:
'wordpad.exe': Loaded 'C:\Program Files\Windows NT\Accessories\wordpad.exe', Symbols loaded (source information stripped). 'wordpad.exe': Loaded 'C:\Windows\System32\ntdll.dll', Symbols loaded (source information stripped). 'wordpad.exe': Loaded 'C:\Windows\System32\kernel32.dll', Symbols loaded (source information stripped). 'wordpad.exe': Loaded 'C:\Windows\System32\KernelBase.dll', Symbols loaded (source information stripped). ...
You can see how Visual Studio loads PDB files (symbol files), which provide a little extra information for them. When you load myctl.ocx , you will see this line. If myctl.pdb is available, it will also download it.
'wordpad.exe': Loaded 'C:\something\myctl.ocx', Symbols loaded.
With this, you can debug anything in myctl.ocx with the source code and everything else. When Wordpress crashes inside myctl.ocx , it should show you the source code and everything, again taking it in an accessible place.