Thanks,
It was a help. Turned out I was running regxpcom from an mks cshell with "/" as
the path seperator. When I switch to a CommandTool and "\" as the seperator I
got past this problem (and right into the another). Now regxpcom crashes when
it tries NS_RELEASE the plugin manager during my RegisterSelf call. If I
comment out the NS_RELEASE then the registration completes, but mozilla crashes
when it calles my Create function (It crashes in QueryInterface on the
GlobalServiceManger)
Steve Katz
In article <[EMAIL PROTECTED]>, John Bandhauer says...
>
>Steven Katz wrote:
>>
>> Can someone tell me what the error code:
>>
>> 80520001 means?
>>
>> I am seeing it when I try and run "regxpcom" against my plugin on Windows.
>>
>> thanks,
>>
>> stevek
>
>I'm sure you just want the answer to your problem. But, I'm going
>to take this opportunity to post a primer on how to find the
>symbolic name for a given error nsresult code (in our system as
>it works today).
>
>The key to deciphering nsresult codes is to understand the stuff
>in nsError.h...
>
>http://lxr.mozilla.org/seamonkey/source/xpcom/base/nsError.h
>
>There are some explicitly predefined result codes (mostly legacy
>numbers to match up with MS HRESULTS). If your number is one of
>those then you can easily determine the symbolic name for the
>number by searching for that number. Using lxr to search for the
>number is best since there *may* be some explicitly defined
>nsresults in places other nsError.h.
>
>For example:
>http://lxr.mozilla.org/seamonkey/search?string=8007000e
>
>But often the number one seeks is not explicitly #defined. It is
>built up using the macros in nsError.h. Deciphering one of those
>requires one to understand those macros (usually
>NS_ERROR_GENERATE_FAILURE) and be able to 'run' the macro in
>reverse using your biocomputer.
>
>#define NS_ERROR_GENERATE_FAILURE(module,code) \
> ((nsresult) (((PRUint32)(NS_ERROR_SEVERITY_ERROR)<<31)
>| ((PRUint32)(module+NS_ERROR_MODULE_BASE_OFFSET)<<16) |
> ((PRUint32)(code))))
>
>Your number (80520001) is in hex. The leading 8 is just the high
>bit being set that indicates it is an error code.
>
>Strip off the high bit and look at the top 16 bits.
>
>You have 0x0052.
>
>Subtract NS_ERROR_MODULE_BASE_OFFSET (which happens to be 0x45 -
>#define'd in nsError.h).
>
>This leaves 0xd. See the list of #defined 'modules' in nsError.h.
>Note that the numbers there are in decimal. So convert 0xd to
>decimal -> 13. This corresponds to NS_ERROR_MODULE_FILES.
>
>#define NS_ERROR_MODULE_FILES 13
>
>Your original number has a low 16 bits of 0x0001. So you are
>looking for a use of the NS_ERROR_GENERATE_FAILURE macro where
>the 'module' is NS_ERROR_MODULE_FILES and the 'code' is 1.
>
>Once you know the module, the easy way to find the answer is to
>search for uses of it in lxr:
>
>http://lxr.mozilla.org/seamonkey/search?string=NS_ERROR_MODULE_FILES
>
>In this case your answer is at
>http://lxr.mozilla.org/seamonkey/source/xpcom/base/nsError.h#236
>
>#define NS_ERROR_FILE_UNRECOGNIZED_PATH
>NS_ERROR_GENERATE_FAILURE(NS_ERROR_MODULE_FILES, 1)
>
>So you are looking at a NS_ERROR_FILE_UNRECOGNIZED_PATH error.
>
>http://lxr.mozilla.org/seamonkey/ident?i=NS_ERROR_FILE_UNRECOGNIZED_PATH
>There are a limited numer of places that is generated. you could
>set breakpoints in nsLocalFileWin.cpp and see what's up if you
>want.
>
>FWIW, XPConnect knows about a limited set of the possible error
>codes (generally, those listed in nsError.h). So, in this case,
>one could find the answer using xpcshell and the script:
>
>for(n in Components.results)
> if(Components.results[n] == 0x80520001)
> print(n)
>
>But, since XPConnect has knowledge of only a limited set, this
>approach will often not do one much good.
>
>Anyway, part of the answer to your question is
>'NS_ERROR_FILE_UNRECOGNIZED_PATH'. Why regxpcom is giving you
>this in your case is another question. Perhaps this clue is
>enough to help you resolve your problem.
>
>John.
