Error messages and troubleshooting
This file gives an explanation of the main messages which might appear or non-obvious things which may happen when you use GoBug. Not all the messages are covered here. Those messages which need no explanation are not dealt with.
Problems when starting GoBug
Problems when starting a debuggee
Problems with GoBug's user interface
Problems when debugging
Problems when closing the debuggee
Fatal problems

Problems when starting GoBug

"This executable requires a file which is missing - HHCTRL.OCX".
Cause: GoBug relies on the Windows system files for its functionality, and it will not start if any of these are missing. If you are missing HHCTRL.OCX (a system file which shows this help file) run the self-extracting file hhupd.exe (help update). This is available from the Microsoft web site.

"You need Version 2 to run under this operating system."
Cause: You are running GoBug Version 1.xx on Windows NT, 2000, XP or Vista. You need Version 2.xx. Visit www.GoProg.com.

"GoBug asked the system for debug privileges, but was not granted them ..."
Cause: You have logged on to Windows NT, 2000, XP or Vista and your user name does not have debug privileges. In WIndows NT, 2000, or XP either log on as administrator or ask the administrator to grant your user name debug privileges. In Vista or higher, for added security in case malicious software has infected the machine, the administrator does not automatically have debug privileges. You will probably need to raise your privilege level to allow you to use GoBug. To do this, right click on GoBug.exe, click "properties", select the "compatibility" tab, and under "privilege level" select "run this program as an administrator", then click ok. Alternatively you could turn off User Account Control ("UAC") in control panel, user accounts.

"GoBug is already running. To run GoBug more than once at the same time, change its name, or run it in a different directory."
Cause: There is a copy of GoBug is already running on the same machine. You cannot run two instances of GoBug on the same machine without changing its name, or (better) running it in a different directory see GoBug.exe.

"The file containing the GoBug configuration (GoBug.ini) was found to be the wrong version or was corrupted. Do you agree that this may be deleted and replaced?"
Cause: From time to time the ini file format may change in new versions of GoBug. In that case if you change to the new version and you have not removed an ini file which was used by a previous version, this message will appear.

"The file containing the GoBug configuration (GoBug.ini) was not found so a new one was made"
Cause: This may appear when you first use GoBug, because the ini file is not normally shipped with it. The ini file needs to be in the same directory as GoBug. If you change the name of GoBug.exe so that you can run it more than once, you will see this message since a new ini file is created matching the new name of the executable. When a new ini file is created all GoBug's defaults are restored.

"The system has reported that GoBug's current hot key is already reserved by another application. To use a hot key you will need to set a different one using the settings menu. Alternatively close the other application and restart GoBug, or if necessary, reboot."
Causes:
1. There is another application which is using the same hot-key as GoBug. Gobug's default hot-key is Shift-Pause. If another application has already reserved this hot-key you can change it from GoBug's settings menu.
2. You have two or more copies of GoBug running at the same time. Normally GoBug will not allow you to do this, but it can be done if you change the name of the Exe or if you run GoBug from another directory. See GoBug.exe.
3. GoBug is careful when it terminates normally, or via its exception handler, to clear up all the resources it has used, including the hot-key, which should then be cleared from the system. In fact even if a program does not bother to do this the system will clear up. However, it is possible that neither GoBug nor the system was able to clear up properly, so that the hot-key remains registered with the system. In this event, when GoBug restarts you would see the above message. If this happens if you want to use the hot-key you would need to register another from GoBug's settings menu. Alternatively you could reboot, which would clears all hot-keys from the system.

I am starting GoBug normally but the main window does not appear.
Cause:
The most likely cause of this problem is that the GoBug.ini file has got corrupted (GoBug receives its instructions for the size and position of the main window from the ini file).
Solution:
Delete the GoBug.ini file. Note that if you renamed GoBug, the ini file will also have the new name.

"Sorry there was an error starting GoBug during starting procedure No. ..............."
"Sorry, the system did not respond correctly to GoBug during procedure No .............."
Cause: This is a message from GoBug's exception handler showing something went wrong with GoBug. Hopefully you will never see these messages!

Problems when starting a debuggee

"Sorry, file not found" or"Sorry, path not found"
Cause: A file or path was specified which could not be found when GoBug tried to debug it.

"Sorry, access to this file denied"
Cause: A file was specified which could not be opened when GoBug tried to debug it.

"Sorry, cannot debug this file. Is it a 32-bit executable?"
Cause: GoBug found that the proposed debuggee was not an executable in 32-bit PE file Windows format. GoBug cannot debug any executable which is not in this format. This error message will also appear if you try to load a Dll from the command line. Dlls can only be debugged by first loading as debuggee the exe file which uses the Dll.

"The PE signature was not found in the debuggee image."
Cause: The executable which was loaded (as the debuggee) appeared to be a Win32 executable, but its PE signature was missing suggesting it is corrupted or is not, in fact a Win32 file.

"The PE signature was not found in a dll or loaded process."
Cause: A Dll loaded by the debuggee or an exe created by the debuggee was found not to have a PE signature suggesting it is corrupted or is not, in fact a Win32 file.

"There is problem getting information about this debuggee."
Cause: The executable which was loaded appeared to be a Win32 executable, but it not seem to be quite in the correct format. It is probably corrupted in some way.

"There is problem getting information about a dll or loaded process."
Cause: A Dll loaded by the debuggee or an exe created by the debuggee was found not to be in quite the correct Win32 format. It is probably corrupted in some way.

"Could not find symbols for the debuggee. GoBug looks for COFF or CodeView symbols embedded in the image. It can also get CodeView symbols from a pdb file, COFF symbols from a DBG file, or symbols from a MAP file (Borland or Microsoft type). Check your linker settings, or for the time being you can proceed without symbols".
Cause: Self explanatory but see GoBug as a symbolic debugger.

"Debug information was wrong format. Check linker is giving the correct output. For the time being you can proceed without symbols.
Cause: In this case some debug information was found (either embedded or in a dbg, pdb or map file) but it was unreadable because it was in the wrong format, or it was found to be corrupted. See GoBug as a symbolic debugger.

"GoBug found a map file made at 08:30 on 23rd February 2004 but Testbug.exe was made at 09:30 on 23rd February 2004. Do you want to use this map file bearing in mind it was not made at the same time?"
Cause: At load up a map file was found which did not appear to correspond to the executable being loaded because it had the wrong timedate. (Note that the data and time given in the message will be adjusted to allow for the current daylight saving setting on your computer)See Search procedures for map files.

Problems with GoBug's user interface

When moving Gobug's main window or inspectors the background is not repainted
Cause: If GoBug is above the debuggee and the debuggee's execution is suspended in the debug loop (or because you are viewing the log) then the debuggee will not repaint. If this is not the case then the window underneath GoBug may not be responding for one reason or another. In single-user Windows you can see if this is the case by pressing Ctrl-Alt-Del once only (otherwise use the Task Manager). A window appears showing any windows that the system is aware of which are not "responding" (ie. not returning from the window procedure). Another possible cause is as follows. Windows sends a WM_PAINT message to any windows uncovered in a move operation. The uncovered window ought to respond to the message in its window procedure by redrawing itself. If the uncovered window tries to draw to any portion of the screen which is not "invalid" such drawing will be ignored by the system. It may be the case that the system has lost track of which area of the screen is invalid.

The debuggee window tries to come to the foreground but is improperly painted
Cause: This and other similar visual effects can be caused by the suspension of the debuggee in the debug loop while executing window messages. For example, the action the debuggee would take if it were free to do so might be to appear in the foreground. However, it cannot do so because it is being suspended. If you single-step message break over various messages, the debuggee's action will be completed step by step.

Zone Alarm Pro triggers when GoBug's hot key is pressed, or at other times.
Cause: Zone Alarm Pro has probably sensed an effort by GoBug to get into the foreground.
Solution: Disable the alert by going to Zone Alarm, Program Control / Programs then set the Access / Trusted column forGoBug.exe to Allow.

My Unicode section names don't appear correctly.
Using the GoAsm assembler you can specify a section name using non-Roman characters if you are using a Unicode editor. The "Go" tools store section names in the object file and in the executable in UTF-8 format. In the executable, however, there is only room for section names of 8 characters, and so if you have used non-Roman characters there is a high possibility that the section names (in UTF-8 format) will be longer than the available space of 8 characters. The result is that such names will be truncated and the last visible character will be corrupted.

My Unicode characters do not appear properly in my dumps.
Using the "Go" tools, you can use non-Roman characters for code and data labels (symbols). These will only appear properly in your dumps if you specify dump to a UTF-8 or UTF-16 file, and view the resulting file using a Unicode editor.

Problems when debugging

My application uses Structured Exception Handling for signalling and the exception dialog keeps appearing.
Cause: Structured Exception Handling may be used by an application as a signal, for example if more memory is required. In that case a read/write exception might occur and the exception handler is supposed to provide the extra memory required.
Solution: There is no solution to this since GoBug cannot differentiate between an application's intentional exceptions and errors. When such an exception occurs ensure that you click the second radiobutton in the exception dialog, allowing the debuggee to deal with the exception itself. Note that the Windows system often uses SEH for signalling and testing. I have found that such exceptions occur during calls to HHCTRL.OCX (to show help), and also in other instances, for example within the IsBadReadPtr API. System exceptions caused in this way are in fact sent to GoBug but GoBug ignores them and does not log them.

I know the debuggee is loading a Dll but I cannot see it in the log, nor in the "Information about debuggee" pane.
Cause: This can happen if the name of the Dll was changed. When a Dll is loaded, GoBug is informed about this by the system, but GoBug is not given the name or path of the Dll. GoBug has to find the name by looking inside the Dll at the export directory (which is the only place insider the Dll where the name is available). The name in the export directory is inserted by the linker at compile-time and will therefore be the original name of the Dll, not the name as changed. Because the name GoBug gets for the Dll will be wrong it will be unable to find the path for the file either. The same can happen in the unlikely event of a Dll which has no exports (and therefore no export directory!).

"Sorry, access denied by the system."
Cause: When making an inspector it was found that the system will not permit inspection of the chosen area of memory. Remember that the memory addresses are all by reference to the debuggee's memory context or in shared memory. It is possible that the memory address you are trying to inspect is not allocated by the system at all, or is marked not readable.

"Sorry, access no longer available."
Cause: This message is found in data inspectors when the system no longer allows access to the memory area covered by the data inspector. This will occur when the memory area has been freed by the debuggee for example, by calling VirtualFree.

"Sorry no symbols were loaded."
"Sorry since no symbols were loaded, you cannot specify that you want to view one!"
"Sorry since no symbols were loaded you cannot specify a symbol to run to."
Cause: You are trying to use symbols, but when the debuggee was loaded no symbols were found. See GoBug as a symbolic debugger.

"Sorry, GoBug does not know this data symbol."
"Sorry, GoBug does not know this code symbol or procedure."
Cause: One of these messages may appear if, in the run to .. procedure or view .. procedure dialog, you have entered a symbol which is not recognised by GoBug. This might happen if you have made a mistake. It might also happen if a symbol inspector or breakpoint was used in a previous session with the same debuggee, and you are trying to use the same inspector or breakpoint, but the symbol is missing in this session. The symbol might be missing if the debuggee has now been linked without debug information. Or it might be missing if you have removed the symbol concerned from the source code. See sessions.

Some of my symbols containing the '@' character do not appear properly.
Cause: Some development tools "decorate" some symbols using a leading underscore and '@' followed by a decimal number. This indicates to the tools that the symbol accepts parameters (the decimal number gives the number of bytes in the parameters). When displaying these symbols GoBug removes the decoration, but this means that if you use '@' in your symbol names followed by a decimal number these characters will not appear in GoBug's symbol table.

"No exact match, do you mean ...................?"
Cause: You are entering a symbol name in a dialog but the symbol is not recognised by GoBug. You will be asked if you meant to enter the symbol which GoBug thinks you might have meant instead.

"Sorry cannot disassemble at present".
Cause: This message appears in the codepane if the current instruction of the thread being displayed appears to be outside any known code sections, or if the memory area concerned is unreadable.

Some lines of the disassembly show the wrong mnemonics.
Cause: This can happen if the compiler used to make the exe has inserted zeroes for padding. If that happens, GoBug will not know whether the zero is part of an opcode or not. Here is an example of what can happen:-

Solution: Instruct the compiler to pad with NOPs (opcode 90) instead.

"You must enter a 64-bit hex number eg. 54100A23842F922Ch."
"You must enter a 32-bit hex number, eg. 54100A23h or 842F922Ch."
"You must enter a 16-bit number eg. 13F0 or 21B4"
Cause: These messages are typical of number-entering error messages. When entering hex numbers, delete the existing digits first and then insert the new digits. The "h" is optional. In some cases spaces are ignored, for example when amending MMX or XMM registers.

"You must enter a decimal or real number eg. 2,001 or 3.142 or 22.625E4."
"Exponent must be between -4932D and +4932D"
"That is an invalid exponent - it must be a decimal integer"
"The number is too small to be resolved into the floating point register"
"The number is too big for the floating point register".
Cause: These messages may be encountered if errors are made when amending the contents of the floating point registers. The "D" at the end of the exponent message emphasises that the number must be in decimal, but you do not need to enter this. See real numbers or changing the floating point registers.

"This is not a recognised handle or 16-bit selector".
Cause: You were asked to enter a handle or 16-bit selector but the system reported that it was not recognised. The test is carried out using the API GetThreadSelectorEntry. Remember it only works for memory addresses within the debugee's own memory context, or in shared memory.

"You are about to step into a system API or other code in shared memory run by the system. This is normally not permitted and may cause problems, for example, a. there may be a thunk to 16-bit code which GoBug cannot follow. b. the system may switch contexts so you may lose the trap flag. c. The system may close the debuggee if it senses your presence. Do you wish to proceed?"
Cause: You are using GoBug with Windows 9.xx and have pressed F5 (to single-step) and the next instruction will cause execution to take place in a system Dll. When using GoBug with Windows NT/2000/XP this message does not appear. Obviously before you single-stepping into a system Dll or any third party product which is protected by copyright you will need to have legal permission to do so.See single-stepping into Windows code.

"GoBug is trying to intervene in the execution of the debuggee but some of its code appears to be shared by another process! Bearing in mind the other process might be affected do you wish to proceed?"
Cause: You have probably sought to get a running thread of the debuggee into the debug loop by using the traffic light control, and GoBug is flooding the code with breakpoints to try to achieve this. During this process GoBug found that a code section had "shared" characteristics and GoBug did not want to cause any other executable to break on the breakpoint it was inserting without asking you first. See regaining control of wayward threads.

"Breakpoint not allowed in code areas shared by another process."
Cause: You are trying to set a breakpoint in a code area which GoBug has identified as shared by another process. Under Windows 9.xx, the test carried out by GoBug is simply whether the code area is in shared memory (above 7FFFFFFFh). Under NT/2000/XP more sophisticated tests are required.

"Please first press F5/6 to move the debuggee past the proposed breakpoint."
Cause: You are trying to set a breakpoint at the current eip. GoBug is unable to jump over the current eip to set the breakpoint, because it cannot be certain that it will keep control of the debuggee. You will need to single-step once to get the debuggee onto the next instruction. Then you can set the breakpoint.

"GoBug tried, but could not trap the following threads .............".
Cause: You have probably sought to get a running thread of the debuggee into the debug loop by using the traffic light control, and GoBug flooded the code with breakpoints to try to achieve this. However this action failed in the case of the threads listed. This would probably be because those threads are suspended or currently in a system API which has not yet returned."See regaining control of wayward threads.

"Tried, but failed, to trap a thread".
Cause: This message appears if you press the hot-key and GoBug was unable to get any of the debuggee's threads into the debug loop. See regaining control of wayward threads.

"No action taken by GoBug (debuggee already waiting in debug loop).
Cause: You have probably sought to get a running thread of the debuggee into the debug loop by using the traffic light control. However, GoBug did not do this because a thread is already in the debug loop. Accordingly the whole process of the debuggee and all its threads were suspended. See regaining control of wayward threads.

"The trap for this thread has been released. Try setting a breakpoint to trap it (or try the hot-key)."
Cause: You have probably pressed one of the "action" keys (F5 to F9) but the thread currently displayed in the codepane is currently running without a trap (F8 or F9 action). Therefore GoBug could not respond to the key. See regaining control of wayward threads, how to set a breakpoint, the hot-key.

"The thread currently showing no longer exists!"
Cause: You have probably pressed one of the "action" keys (F5 to F9) but the thread currently displayed in the codepane has terminated. Unless single-stepping or a breakpoint is reached it is normal for the display to continue to show a terminated thread (although it will be greyed). See debugging multi-threaded applications.

"The thread currently showing is in a procedure which has not yet returned:- ..........."
Cause: You have probably pressed one of the "action" keys (F5 to F9) but GoBug could not respond to the key because the thread is not in the debug loop. This particular message is given if the relevant thread has not yet returned from a procedure, known to GoBug. The eip of the CALL instruction is given (if known) and the codepane will show the call. Normally you will also see the eip arrow animate. See the debug loop.

"The thread currently showing has not yet returned from the window procedure"
Cause: You have probably pressed one of the "action" keys (F5 to F9) whilst ignoring a message having pressed F6 after a single-step message break. Whilst ignoring a message GoBug retains control of the thread by setting the trap in the debug loop upon each instruction. This will slow down the debuggee and if it has a lot of work to do on a particular message there may be some delay before the message has been dealt with.

"The thread currently showing is in code at eip=.........."
Cause: You have probably pressed one of the "action" keys (F5 to F9) but GoBug could not respond to the key because the thread is not in the debug loop. This particular message is given if the relevant thread has not yet returned from certain code, but GoBug does not know which procedure it is in. See the debug loop.

"The thread currently showing is currently in GoBug's hook procedure."
Cause: You have probably pressed one of the "action" keys (F5 to F9) but GoBug could not respond to the key because the thread is not in the debug loop. This particular message is given if the relevant thread is in code in GoBug.dll (which holds GoBug's hook procedure in the debuggee's address space). This usually means that GoBug was still working on the event or message when you pressed the key. See the debug loop, how GoBug monitors events and messages.

"GoBug has no idea what happened to the thread currently showing."
Cause: You have probably pressed one of the "action" keys (F5 to F9) but GoBug could not respond to the key because the thread is not in the debug loop. This particular message is given if the information about the thread cannot be relied on.

"Please inform JG@JGnet.co.uk as follows:-
GoBug Version ......... At Eip=............ Could not read memory at ............../Unexpected result 103/16-bit Kernel could not be found".
Cause: These are messages from GoBug's exception handler called during an attempt to get information about the debuggee possibly during a promenade. These are not fatal messages, and, although there was a problem during information gathering, this was anticipated and will have been swallowed up by the handler.

"There are too many "finds". The search needs to be more specific."
Cause: When searching debuggee or shared memory, the result box was in danger of overloading due to the number of "hits". The maximum number permitted is 5,000. See searching memory..

I gave my sections names, but they appear truncated.
The reason for this is that the PE file specifications do not allow for section names more than 8 bytes long. If the names use Roman characters (for example, English), then the maximum length is 8 characters. If the names use non-Roman characters, they may be truncated even further, since they have to be kept in the executable in Unicode which takes up more space.

I cannot amend the MMX, 3DNow! or XMM registers
The reason for this is probably that the registers you are trying to amend are not available on your processor. A warning line should appear in the register pane to tell you this. See MMX, FPU, 3DNow!, XMM, SSE and SSE2 register panes to see what registers are available on what processors.

You are changing the contents of a floating point register in the FPU by hand but the "value" still shows as empty.
Cause:
The tag word is set to "empty" for the register concerned.
Solution:
Fill the register either by loading a number normally (by single-stepping over an FP load instruction) or change the contents of the corresponding MMX register to change the tag word.

"Exponent cannot be larger than +4001h or smaller than -3FFEh."
Cause: You are changing the contents of the floating point registers by hand, but you have put in an exponent which is too large or too small. See changing the floating-point registers for the relevant values in the FPU. Different values will apply in the 3DNow!, SSE and SSE2 floating point registers.

"Full register data has been lost."
Cause:When trying to view the state of the registers in the log, GoBug was unable to find the information required. To save memory, GoBug keeps only changes to the registers in the log. When the registers are being displayed, GoBug has to go back to the last known register values to complete all the information required to show the state of the registers at any given time. This message may well appear if this earlier record has been removed, for example if you cleared the log using the "settings, clear log" menu item. It could occur if the earlier record has looped away and the thread has terminated.
Solution
View the log before the thread in which you are interested has terminated. Alternatively enlarge the amount of memory used by the log to stop earlier records looping away so quickly. Alternatively use a breakpoint at the beginning of the code in which you are interested - this causes GoBug to make a complete record in the log of all registers.See The log and the log panes or Debugging using the log.

"part of the record looped away"
You may see the following in the log: "part of the record looped away".
Cause:This may appear in the log if the log memory is full and in order to make space for later records, earlier records had to be abandoned. This is not normally a problem but you can reduce the amount of log memory used up by running to the code area in which you are interested using breakpoints. This is because nothing is logged when running to a breakpoint. See The log and the log panes or Debugging using the log.

"Sorry, could not establish memory areas - memory resources must be low."
"Floating point pane needs 4K of memory but the system could not provide this."
Cause: These messages are typical of "low memory" messages or some other problem showing that the system is no longer serving GoBug. Close down applications, save work and reboot.

"Sorry, could not create the file."
Cause: This message is typical of file creation error messages when you are trying to dump to a file, or extract resources. Possible causes are disk full, filename same as another file, or path does not exist.

"GoBug could not perform this task."
Cause: This is a generalised message shown if GoBug could not do something it was asked to do. Since it is reserved for unusual events for which an explanation would probably not be required, no further detail is given in the message.

The single-step message break is not cutting in on messages which I know are being sent.
Try:
Check that the single-step message break is switched on for the thread you are dealing with. You can check this by using the traffic light control. You can also switch the single-step message break on and off for the main thread or for new threads from the "actions" menu. Note also that the single-step message break ignores messages which are ignored by the log. This is by design and the log ignores can be changed by using the menu item "settings, log settings" and the tab "ignores".

"The message you are running to occurred but it was going to shared memory and could not be trapped"
Some messages are sent only to system Dlls in shared memory unless you sub-classed the window class. Examples are TB_ADDBUTTON (which adds a button to a toolbar) or LB_ADDITEM (which adds an item to a listbox). Your application would send these messages to the common control window concerned, and the window procedure will be in a system Dll. Since system Dlls are in shared memory (in W95 and W98 anyway) you cannot trap the message. This is because if you tried to do so it could bring other applications to a halt as well.

When printing some lines are missing from the printed page or the paper is too narrow for the printed material.
Cause: When getting ready to print, GoBug gets its information about the printer and the paper size from the system. If material is missing from the edges of the paper, probably the paper you are using is not the same size as is specified in the printer "properties" dialog box.
Solution: Using the start menu, go to "settings, printers", right click on the default printer and check in "properties" that the specified paper size is the same as the paper you are actually using.

Problems when closing the debuggee

"The debuggee has closed. Click OK to close the panes."
Cause: The debuggee was closed (either its main window closed or it finished processing and called ExitProcess, or otherwise returned to the system). If this was unexpected, it is possible the system threw out the debuggee. This might occur, for example, if you tried to single-step through system code. See single-stepping into Windows code.

"Could not close the debuggee in the usual way there may be system conflicts. Ensure you save all work in other applications before closing this message box."
Cause: GoBug makes every effort to close the debuggee cleanly, however, sometimes this is not possible. If this message box appears it is possible that the system resources will become over-stretched or a hidden fault may arise. If you are carrying out any critical actions it may be sensible to reboot after seeing this message. See how GoBug closes the debuggee.

Fatal problems

"Sorry there was a serious error and GoBug version .... will have to close. It will try to do this without affecting other parts of the system. There was exception .............. at eip=............ Please inform Jeremy Gordon on JG@JGnet.co.uk and get the latest version of GoBug from http://www.GoDevTool.com (or from http://www.GoProg.com)"
Cause: This is a message from GoBug's exception handler. An error has occurred within GoBug. This is probably a bug which slipped past testing during development. Sorry! As a developer yourself, you will understand. Every reasonable effort was made to eradicate any bugs.