error compiling CHM on network drive
Bill Starr
error when I compile to/from a network drive, but not when I copy the
same files to a local hard disk and compile there. Has anyone else
encountered anything like this?
Any suggestions for fixing the problem?
I am compiling about 25 CHM files, all structured very similarly. The
other 24 all compile without errors on the network drive. I would like
to be able to compile them all in that environment.
There is ample free disk space on the network drive. Deleting and
recreating the directory tree in which I do the compile does not help.
Following are the highlights of the error messages I am receiving from
the compiler.
I have duplicated the problem on both a Windows NT and a Windows XP
PC.
The compiler displays all of the component HTML & GIF files as it
processes them, and the error pops up just after the final file is
displayed in the Command Prompt.
Virtually the same error occurs using Html Help Workshop (hhw.exe) to
compile instead of "hhc.exe".
The other perplexing issue is that the failed compile attempt leaves
an invalid ".chm" file. The correct file size when I compile without
errors on the hard disk is 3.92MB. The CHM from the failed compile is
3.72MB. The CHM from the failed compile sometimes does not open at
all, giving the error:
Help: Cannot open the file:
mk:@MSITStore:O:\chm_FIS\3666288\FIS3666288.chm
I found a MS KB article about this message:
http://support.microsoft.com/?kbid=312456
It recommends confirming that I have the current version of
"hhctrl.ocx" and confirming it is registered.
My "hhctrl.ocx" is 20 Dec 2002, 3:38pm, 5.2.3735.0. It appears to have
been part of Critical Update Q811630.
I also successfully [re]registered this file as indicated (with paths
modified as needed for XP), and this did not have any effect on the
error.
Other times, it opens, but with only a "page cannot be displayed"
error.
Whether the compile succeeds or fails, ERRORLEVEL seems to get set to
zero when "hhc.exe" runs. Does anyone know a reliable means of testing
for successful completion of "hhc.exe" from a script? Presently, I
don't think the script which invokes "hhc" will even continue until I
manually dismiss the popup error message, so having a means to detect
the problem may be somewhat of a moot point.
If this inquiry might be better posted in some other newsgroup (e.g.,
"comp.os.ms-windows.programmer.winhelp", "microsoft.public.htmlhelp"),
please let me know. I don't remember where to find the scope / charter
of all of the different groups.
Thanks, Bill
Fri, 31 Oct 2003, 11:21am EST
*****
Microsoft HTML Help Compiler has encountered a problem and needs to
close. We are sorry for the inconvenience.
For more information about this error, click here.
Error signature
AppName: hhc.exe
AppVer: 4.74.8702.0
ModName: hha.dll
ModVer: 4.74.8702.0
Offset: 000217d8
To view technical information about the error report, click here.
Error Report Contents
The following information about your process will be reported:
Exception Information
Code: 0xc0000005
Flags: 0x00000000
Record: 0x00000000
Address: 0x453217d8
hhc.exe - Application Error
The instruction at "0x453217d8" referenced memory at "0x096be000". The
memory could not be "read". Click on OK to terminate the program.
![Rob Chandler [MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Rob Chandler [MVP]
HH Compiled does have its little instabilities.
And for some reason one machine may compile
a CHM while another fails. HHC.EXE can failed
but HHW.exe can suceed. My FAR.EXE program
can sometimes suceed where HHC and HHW fail.
Neither we or Microsoft have ever discoved the
real reason for this. Behind it all is the same
compiler DLL HHA.DLL and its sub components.
However, in the last 8 years I've seen HH compiler
become more stable and robust. We never have
problems any more. The only time we DO have
problems is when there is a problem with file name
format or HTML format.
And normally if you study the logs the compile always
falls over at exactly the same place. It appears that
while some programs get destabilized by these inperfections
others hang on by the skin of their teeth and keep running till
the end.
Rest assured though in ALL cases we have ALWAYS found
an imperfection in the filename or HTML was at the bottom of the crashes.
===================
From http://helpware.net/FAR/far_faq.htm#HTML_Help_Compilation
The MS HTML Help compiler is a DLL (HHA.DLL) installed with HH Workshop.
Thus when it crashes it will also cause it's host application (FAR,
Workshop, etc) to crash also.
There are a number of reasons why the MS HH compiler may crash.
1. Invalid filenames
The HTML Help compiler does not like some filenames. Try and stick
with these characters _, a..z, A..Z, 0..9.
Do not use periods apart from in the normal file extension. Example: A
filename such as xxx.h001.gif is identified incorrectly as a HTML file. The
compiler then attempts to parse the binary file and crashes.
I believe that spaces in a filename can still cause some minor
problems with HTML Help. Best to replace spaces with underscores.
2. Invalid Tags or Characters
Certain sequences of HTML tags and characters can crash the compiler.
a.. A web file may have become corrupted.
b.. A FrontPage _vti file may have been included in your compile.
c.. A stray control character may have been left in a HTML file.
d.. Your HTML editor may have produced code not understood by the
parser in the MS compiler.
3. Insufficient Memory
If the help web is big (>10MB) then try recompiling on a more powerful
PC (eg. Win2K, 256M RAM, lots of harddisk space on the system drive). If it
successfully compiles then you know that free memory is the problem.
Debugging:
You need to debug your help system. You need to identify the file(s) that
are crashing the compiler.
I normally remove sections of the web by renaming or moving folders and
files, then recompile. Keep adding and removing sections until the compiler
does not crash. Eventually you will find one or two files that are causing
the problem. You may also need to debug these files by temporarily removing
sections of the HTML file.
Note: A good starting point is to watch the compile log file being
displayed and try to see where the crash appears. Tip: You may need to press
PrintScrn (captures the screen to the Windows clipboard) just before the
crash to be able to read the list. The compiler normally follows the list of
files in the .hhp project file then searches for addition files by examining
the .hhc and .hhk files.
--
Rob Chandler
MS Help MVP
http://helpware.net/FAR/
"Bill Starr" <bill.sta...@spamex.com> wrote in message
news:ce6bdfc1.0310...@posting.google.com...
Bill Starr
> HH Compiled does have its little instabilities.
> And for some reason one machine may compile
> a CHM while another fails. HHC.EXE can failed
> but HHW.exe can suceed. My FAR.EXE program
> can sometimes suceed where HHC and HHW fail.
>
> Neither we or Microsoft have ever discoved the
> real reason for this. Behind it all is the same
> compiler DLL HHA.DLL and its sub components.
>
> However, in the last 8 years I've seen HH compiler
> become more stable and robust. We never have
> problems any more. The only time we DO have
> problems is when there is a problem with file name
> format or HTML format.
>
> And normally if you study the logs the compile always
> falls over at exactly the same place. It appears that
> while some programs get destabilized by these inperfections
> others hang on by the skin of their teeth and keep running till
> the end.
>
> Rest assured though in ALL cases we have ALWAYS found
> an imperfection in the filename or HTML was at the bottom of the crashes...
Thanks, Rob.
I had the same error when I tried using "FAR.EXE" to compile.
I'm not at all confident that I found the real root cause, but I have
apparently at least found a "band-aid" that works around it.
I replaced the file "100-002_EngineDiagramsNotFound.htm" with just
"100-002.htm" and it seems to compile okay. Nothing really very fancy
in the original name.
This is rather odd, since the same long filename compiled fine on a
local hard disk (but not on a network drive), and another, very
similar CHM file compiled without error on the network drive with
exactly the same long filename.
Regards, Bill
Tue, 11 Nov 2003, 1:15pm EST
Rob Chandler [MVP]
Interesting. Who knows. Maybe by changing that filename
you effected memory in some way and it now gets through.
Glad you found a way through.
--
Rob Chandler
MS Help MVP
http://helpware.net/FAR/
"Bill Starr" <bill.sta...@spamex.com> wrote in message
news:ce6bdfc1.03111...@posting.google.com...
kovs...@gmail.com
> error when I compile to/from a network drive, but not when I copy the
> same files to a local hard disk and compile there. Has anyone else
> encountered anything like this?
>
> Any suggestions for fixing the problem?
>
....
> memory could not be "read". Click on OK to terminate the program.
The problem is in file hha.dll. In brief it just out of bounds error.
in pseoudo code it looks like
find_something(int data[count],int key) {
for(i=0;i<count;++i) if (data[i]==key) break;
if (data[i]==k) // here is AV (i==count) data[i] is out of bounds
success;
else
no_result;
}
To fix it you should change file hha.dll using any hex editor
HHA.DLL
00020BD5: 8D 39
00020BD6: 04 D0
00020BD7: 40 8D
00020BD8: 39 04
00020BD9: 3C 40
00020BDA: 81 90
00020BDE: 74 75
format: offset old_byte new_byte
then place hha.dll near hhc.exe and itcc.dll
This should solve the problem with full text index.
Gloops
That is interesting, could you explicit what instruction this implements ?
By the way, I wonder why it is so much a good idea to compile to a
network drive, rather than first compiling locally, and copying the
results to the network afterwards. I mean concerning the amount of
traffic on the network ...