Processing of sehexception external component exceptions when unrar. dll is called

Recently, unrarnet is used to process RAR compressed files. Unrarnet is an encapsulation of the. NET platform provided by rarlab along with the unrar. dll Control. Unrarnet uses the VB.net language. It should be said that unrar. dll is encapsulated almost perfectly, and almost all the compression and decompression work is done beautifully.

However, a system. runtime. interopservices. sehexception exception was encountered during a recent test of file decompression. The exception message is "external component exception ". The specific location is in the loadfilelist () method of the decompressor class.

Mrarhandle = Raropenarchiveex (urarex)

Is to call the raropenarchiveex () method of the unrar. dll external component. The exception occurs here.

Microsoft's description of sehexcption:

Sehexception Class processing from unmanaged Code The seh error that is thrown but not mapped to another. NET Framework exception. Sehexception Class response Hresult e_fail (It has a value Zero X 80004005 ).

. NET Framework often encounters unmanaged seh exceptions, which are automatically mapped to managed equivalents. For example,Status_no_memorySeh exceptions are automatically mapped to the outofmemoryexception class, whileStatus_access_violationSeh exceptions are automatically mapped to the nullreferenceexception class. However, by default, any seh exceptions that are not automatically mapped to a specific exception will be mappedSehexceptionClass.

I used Google to search web pages and Google groups, but I didn't find any way to solve these problems. It seems I am lucky enough.

After careful analysis, it is found that the problem lies in the comment of the compressed file. When the comment length exceeds a critical value, sehexception external component exception occurs. The RAR command guide mentions that the maximum comment length of the RAR compressed package is 62000 bytes, while the compressed file comment in the test is only more than 19000 bytes, which does not exceed the maximum comment length. It seems unreasonable to have an exception because of the annotation length. Is there a problem with unrarnet?

looking back at the decompressor class, we found that there is such code in the init () method:
urarex. cmtbuf = space ( 16384 )
urarex. cmtbufsize = 16384
urarex. arcname = mrarfile

Uheaderex. cmtbuf= Space(16384)

It turns out that unrarnet sets the default comment length to 16384. No wonder an exception occurs during decompression. Set the comment length to the maximum comment length of the RAR compressed package by 62000. The test passes :)