PS: I know there is defer recover mechanism in Go that can be used to 
handle exception... But I would like to use AddVectoredExceptionHandler 
(maybe it is already used behind the scene with defer recover ?) because I 
can inspect the thread context in myhandler function

Le vendredi 17 janvier 2025 à 13:17:07 UTC+1, rudeus greyrat a écrit :

> I want to be able to catch windows exception and do stuff with it (mainly 
> for hardware break point later).
>
> I created a custom function to add a Vectored Exception Handler using the 
> windows API call AddVectoredExceptionHandler:
> ```
> func AddVEH(myHandler PVECTORED_EXCEPTION_HANDLER) error {
>     kernel32 := syscall.NewLazyDLL("kernel32.dll")
> addVectoredExceptionHandler := 
> kernel32.NewProc("AddVectoredExceptionHandler")
>
>     
> _, _, err := addVectoredExceptionHandler.Call(
> uintptr(1),
> syscall.NewCallback(func(exceptionInfo *EXCEPTION_POINTERS) uintptr {
> return myHandler(exceptionInfo)
> }),
> )
>     if err != nil {
>         fmt.Println("Error Setting the VEH")
>         fmt.Println(err.Error())
>     }
>     return err
> }
> ```
>
> I test it with a custom exception I raise:
> ```
> func myHandler(exceptionInfo *handler.EXCEPTION_POINTERS) uintptr {
> println("Exception occurred! ---> Code")
> println(exceptionInfo.ExceptionRecord.ExceptionCode)
> println("It happends in life, lets continue")
> return ^uintptr(0) // EXCEPTION_CONTINUE_EXECUTION = -1
> }
>
> func main() {
> handler.AddVEH(myHandler)
>
> raiseCustomException() // Just Raises a custom EXCEPTION with 
> RaiseException winapi and code 0xE0000001
>
> println("Continued")
> }
> ```
>
> As I return with EXCEPTION_CONTINUE_EXECUTION, I expect that 
> `println("Continued")` will be executed. However, it is not the case at all:
> ```
> Error Setting the VEH
>     The operation completed successfully.
> Exception occurred! ---> Code
> 3758096385
> It happends in life, lets continue
> Exception 0xe0000001 0x7eb71d5fb17c 0x1b 0x7ffc54e4b699
> PC=0x7ffc54e4b699
>
> runtime.cgocall(0xf1dde0, 0xc000049b30)
>         runtime/cgocall.go:167 +0x3e fp=0xc00006fe28 sp=0xc00006fdc0 
> pc=0xf10a7e
> syscall.SyscallN(0xc00001e410?, {0xc0000121c0?, 0x0?, 0xf39a00?})
> ```
>
> As you see the program enter the handler function but never continues, 
> rather it exit and print the stack trace... 
>
> Not sure if it is because of syscall.NewCallback or something else ...
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/golang-nuts/de967171-5589-41d6-9ad1-071aec79c628n%40googlegroups.com.

Reply via email to