Prevent third-party dll from crashing PowerShell - exception

I am creating a PowerShell module which uses an unmanaged API. The way it works looks something like this:
PowerShell Module
|
˅
.NET Wrapper DLL
|
˅
Native DLL
This native DLL has two ways of communicating whether an operation failed or not - by writing status codes to stdout or by throwing Win32 exceptions. You can specify your preference by calling the API's UseExceptions() or DontUseExceptions(). However both options suck:
Without exceptions, any time I do a successful function call, 0 gets printed on the screen. If a function call fails, a warning message is printed on the screen. Not only does this make it hard to detect errors, it also clutters up my module's output to the user.
With exceptions, if there's a minor error, the whole PowerShell process will crash because it's a Win32 exception as opposed to a .NET exception.
Is there a way to prevent a Win32 exception from crashing the whole PowerShell process? Or is there a way to intercept this DLL's stdout and parse the status codes myself?
The API I'm using is the widely-used Geographic Data Abstraction Library.

In your .NET Wrapper DLL try catching SEHException to see if you can catch the Win32 exception. Another option is to write the .NET wrapper using CLI/C++ then use the C++ exception handling mechanism to catch the exception.

Related

How should one deal with a new Tcl assertion (introduced in 8.5.18) that fires upon an IO operation?

Our Tcl-based web application (OpenACS, NaviServer) provides the functionality for uploading and extracting ZIP Archives. After upgrading to the latest version of Tcl (8.5.18), the server now crashes when processing the contents of the extracted archive and spits out this error.
nsd: /usr/local/src/tcl/tcl8.5.18/unix/../generic/tclIO.c:5395: DoReadChars: Assertion `!((statePtr)->flags & ((1<<9))) || ((statePtr)->flags & ((1<<10))) || Tcl_InputBuffered((Tcl_Channel)chanPtr) == 0' failed.
This assertion has been introduced between Tcl 8.5.17 and 8.5.18. Is the assertion wrong or too rigorous, or does this hint at some form of error at the application level?
It turns out that I was running into a known bug that was fixed in April 2015 (http://core.tcl.tk/tcl/info/879a0747bee593e2). When Tcl 8.5.19 is released, using that will make my troubles go away. Before that, one can work from Tcl development sources, or try the patch in isolation (http://core.tcl.tk/tcl/info/4b964e7afb811898).

Spring integration | Service Activator - Error Channel , Exception handling

I have a problem in catching the exceptions in my spring integration application.
Flow of operations in my application.
Http:inbound gateway which receives the request (error-channel defined to my custom error channel)
Service Activator for basic validations (Exceptions which are thrown from here are handled by error-channel defined on the GW)
splitter
Aggregator
Exceptions on my splitter or Aggregator are not handled by my error channel. why?
Steps taken:
I added a chain and included a header enricher and specified an error channel just before the splitter.
After this, any exception on my splitter is handled by my error channel mentioned in the header enricher.
<chain input-channel="invitations">
<header-enricher>
<error-channel ref="failed-invitations" />
</header-enricher>
<int:splitter ref="payloadSplitter" />
</chain>
But the same doesnt work when do the same on my Aggregator. why?
Whenever there is an exception in my code, it retries and gets executed more than one time. why?
I have a "errorChannel" defined which logs the exceptions. it doesnt work.
I know the thread is too old, but I was also facing a similar issue and found I declared error-channel in header-enricher but not provide 'overwrite="true"' as a parameter. And after providing 'overwrite="true"'it is working as needed. I am surprised why spring integration does not provide an overwrite=true by default.
Let us know this is what solution you did in your old code? So everyone can find out the solution for such a scenario.

Exception being generated from .net RSACryptoServiceProvider.Enrypt method

Every once in a while, at random times my software crashes due to a an exception with this message:
"Additional information: The runtime has encountered a fatal error. The address of the error was at 0x72938d57, on thread 0xe34. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
If there is a handler for this exception, the program may be safely continued."
It is begin generated from the .net RSACryptoServiceProvider.Encrypt method.
To take a look at it refer to https://github.com/HadiModarres/MRelay/blob/master/ConsoleApplication9/EncryptedRelay.fs line 94
my question is why is this happening and what can I do to catch exceptions that are generated from unmanaged code like this
Reposting from comment:
rsa.Encrypt is not thread-safe.

For Flex remote object calls (BlazeDS), is there a size limitation on objects returned?

I have a production mobile Flex app that uses RemoteObject calls for all data access, and it's working well, except for a new remote call I just added that only fails when running with a release build. The same call works fine when running on the device (iPhone) using debug build. When running with a release build, the result handler is never called (nor is the fault handler called). Viewing the BlazeDS logs in debug mode, the call is received and send back with data. I've narrowed it down to what seems to be a data size issue.
I have targeted one specific data call that returns in the String value a string length of 44kb, which fails (release build). When I do not populate the String value (in server side Java code) on the object (just set it empty string), the result handler is called, and the object is returned, again, using the release build. This works in a debug build.
The custom object being returned in the call is a very a simple object, with getters/setters for simple types boolean, int, String, and one org.23c.dom.Document type. This same object type is used on other other RemoteObject calls (different data) and works fine (release and debug builds). I originally was returning as a Document, but, just to make sure this wasn't the problem, changed the value to be returned to a String, just to rule out XML/Dom issues in serialization.
I don't understand 1) why the release build vs. debug build behavior is different for a RemoteObject call, 2) why the calls work in debug build when sending over a somewhat large (but, not unreasonable) amount of data in a String object, but not in release build.
I have't tried to find out exactly where the failure point in size is, but, not sure that's even relevant, since 44kb isn't an unreasonable size to expect.
By turning on the Debug mode in BlazeDS, I can see the object and it's attributes being serialized and everything looks good there. The calls are received and processed appropriately in BlazeDS for both debug and release build testing.
Anyone have an idea on other things to try to debug/resolve this?
Platform testing is BlazeDS 4, Flashbuilder 4.7, Websphere 8 server, iPhone (iOS 7.1.2). Tried using multiple Flex SDK's 4.12 to the latest 4.13, with no change in behavior.
Thanks!
After a week's worth of debugging, I found the issue.
The Java type returned from the call was defined as ArrayList. Changing it to List resolved the problem.
I'm not sure why ArrayList isn't a valid return type, I've been looking at the Adobe docs, and still can't see why this isn't valid. And, why it works in Debug mode and not in Release build is even stranger. Maybe someone can shed some light on the logic here to me.

lua can't unwind exception, generated by luaL_error on hp-ux

I have a problem with lua... on hp-ux 11.31
I have a lua-script that call some function that has been written on C++.
In that function luaL_error is called... but application crashed then luaL_error is called, because exception isn't unwind by lua...
On other platforms this application is work correct.
Do you have any idea what may be wrong?
You probably need to compile the Lua library as a C++ library, instead of a C library. Then Lua will use C++ exceptions instead of longjmps.