You have to make a reference with other versions of golang since the opcodes might be different in every version. golang_loader_assist uses those opcodes as a pattern to search for strings.

The Ghidra might using the Relative Virtual Address instead of the adding the image base of the binary file.

I think, once you installed the Windows SDKs and use the WinDBG, all the PDBs or symbols that are needed will be downloaded automatically so you can choose the PDB locally.

If you are trying to backtrace where the pop up message was called, you can try to set a breakpoint in MessageBoxA if it uses that WinAPI and check the call stack.

Its not even a shellcode.

Are you sure about the value of instruction pointer in your exception handler? Maybe, you should have to get first the current RIP after the IDIV instruction.

You may refer to this link symantec.com/connect/articles/windows-anti-debug-reference . Its concise, but not complete since there are many types of techniques.

Don't forget to mark an answer as correct.

If you are trying to debug a C# program(.NET) which is not an x86 or x64, use DNSpy, or else, code it in C++ or assembly to debug it in OllyDbg.

Since the file is packed, you cannot find the string you mentioned above even loading it in IDAPro or any disassembler. I think it is the easiest way to unpack the file considering that we already have a tool such as OllyDump and Import Reconstructor.

The main executable itself is packed with MPRESS.

It might be an (0)ordinal number, but it might thrown exception by dividing to zero, in that case, check if there is an SEH.