Commented by: @AlexPeshkoff

Server has absolutely no way to know, how to call UDF, except using information in 'DECLARE EXTERNAL FUNCTION' operator. Imagine you invoke C-function, which expects some parameter to be passed, but instead receives garbage on the stack. No surprise that access violation happens when it's called. This is exactly what happened in your case. Firebird server detects access violation (you see it reported in the log file), and in theory can attempt to continue operation. But (and it was discussed many times before) it's very dangerous from database integrity POV - who knows, what dangerous things might do badly written/called UDF (remember, we can't distinguish that cases) before AV? For example, it could damage database pages buffer. Therefore the only safe action after AV in UDF is to try to log it and restart.

Commented by: Konstantin Dombrugov (abracadabra)

I understand this, and it`s a pity, but question not about calling of udf, but declaration.
Exceptions and processes inside UDF are problems of udf developers, but everybody can declare funciton with wrong params that crashes DBS.

Just a suggestion:
I think It would be better to store info about parameters inside library with UDFs. In this case It`s much harder to declare different parameters. When server processing declaration statement It could check parameters declared by user.
In this case userside declaration can be simplified and look like this:
DECLARE EXTERNAL FUNCTION 'FunctionName'
ENTRY_POINT 'LibNunctionName' MODULE_NAME 'library';