Ошибка приложения код исключения 0x40010006

I register my own vectored exception handler, to catch and trace various exceptions in my application.

Sometimes I get an exception having 0x40010006 code, which is thrown by OutputDebugString function. Certainly, I’d like just to ignore it. What would be the appropriate return value in this case: EXCEPTION_CONTINUE_EXECUTION or EXCEPTION_CONTINUE_SEARCH?

asked Sep 6, 2012 at 10:49

Igor R.'s user avatar

Igor R.Igor R.

14.7k2 gold badges49 silver badges81 bronze badges

You’ll find exception codes listed in the ntstatus.h SDK header file. This one is DBG_PRINTEXCEPTION_C, some likelihood that you typed Ctrl+C to trigger it.

Exception codes with values less than 0x80000000 are just informal and never an indicator of real trouble. In general, you should never mess with exceptions that you don’t recognize and don’t want to explicitly handle. Let Windows continue searching for a handler by returning EXCEPTION_CONTINUE_SEARCH, the debugger will probably catch it in this case.

answered Sep 6, 2012 at 12:52

Hans Passant's user avatar

Hans PassantHans Passant

919k145 gold badges1681 silver badges2525 bronze badges

4

Источник

Коды исключений перечислены в заголовочном файле ntstatus.h SDK. Это DBG_PRINTEXCEPTION_C, есть вероятность, что вы нажали Ctrl+C, чтобы вызвать его.

Коды исключений со значениями менее 0x80000000 являются неформальными и никогда не являются индикатором реальных проблем. В общем, вы никогда не должны связываться с исключениями, которые вы не распознаете и не хотите явно обрабатывать. Позвольте Windows продолжить поиск обработчика, возвращая EXCEPTION_CONTINUE_SEARCH, отладчик, вероятно, поймает его в этом случае.

Источник

Windows 8 Pro 64-bit стоит. До 8.1 не обновлял.

Запись в системном журнале напрягает. Если система работала бы исправно, записей в журнале с ошибками не было бы.

Система работает нормально. Если это можно назвать нормой? Кэш эскизов слетает. Вот уже пару раз видеодрайвер переставал отвечать, и был успешно восстановлен (в игре это было, игра зависала). Перегрева нет.

Вчера обновил утилиты мат. платы ASUS Z87-DELUXE (новая версия вышла 1.00.55), еще проблема появилась – теперь при включении компьютера в журнале запись:

DipAwayMode.exe — Остановка работы (Работа прекращена).

Описание

Неправильный путь приложения: C:Program Files (x86)ASUSAI Suite IIIDIP4DIPAwayModeDipAwayMode.exe

Сигнатура проблемы

Имя проблемного события: APPCRASH

Имя приложения: DipAwayMode.exe

Версия приложения: 0.0.0.0

Отметка времени приложения: 00000000

Имя модуля с ошибкой: KERNELBASE.dll

Версия модуля с ошибкой: 6.2.9200.16451

Отметка времени модуля с ошибкой: 50988950

Код исключения: 40010006

Смещение исключения: 00014b32

Версия ОС: 6.2.9200.2.0.0.256.48

Код языка: 1049

Дополнительные сведения 1: 10bf

Дополнительные сведения 2: 10bfa4501894faa800d73acf9095dac8

Дополнительные сведения 3: e144

Дополнительные сведения 4: e144a35960101920a323cfef23f02e58

Дополнительные сведения о проблеме

ИД контейнера: 0d417ee78a9d4905dbf89d11ec35980f (-568384929)

Описание

Имя сбойного приложения: DipAwayMode.exe, версия: 0.0.0.0, метка времени: 0x00000000

Имя сбойного модуля: KERNELBASE.dll, версия: 6.2.9200.16451, метка времени: 0x50988950

Код исключения: 0x40010006

Смещение ошибки: 0x00014b32

Идентификатор сбойного процесса: 0xdc8

Время запуска сбойного приложения: 0x01ceb380ad5071a2

Путь сбойного приложения: C:Program Files (x86)ASUSAI Suite IIIDIP4DIPAwayModeDipAwayMode.exe

Путь сбойного модуля: C:WindowsSYSTEM32KERNELBASE.dll

Идентификатор отчета: ed17dd2c-1f73-11e3-be87-240a64075e89

Полное имя сбойного пакета:

Код приложения, связанного со сбойным пакетом:

Удалял и заново устанавливал Версию 1.00.55, все равно ошибки.

В Версии 1.00.51 ошибок не было.

DipAwayMode это режим такой — Режим отсутствия типа. В утилите для ASUS включается. Включаешь (кликаешь) – монитор гаснет, кулера на корпусе останавливаются. Мышкой пошевелишь, система заводится (типа спящего режима). Хотя эта функция работает, проверил, несмотря, что запись в журнале: DipAwayMode.exe — Остановка работы.

В общем хрень какая то с компом творится. Не достаточно «обмыл» я его что ли…

Источник

Я пытаюсь запустить функцию из dll с помощью cgo. Библиотека написана на C++, поэтому я создал заголовок C, здесь находятся определенные функции и файл .cpp, в котором находится реализация.

библиотека.ч:

#ifdef __cplusplus
extern "C" {
#endif

void* LoadEngine(char*);

#ifdef __cplusplus
}
#endif

lib.cpp:

#include <Engine.h> //the library

void* LoadEngine(char *sn) {
  Engine *e;
  GetEngineObject(sn, &e); //function from the dll, here it fails
  return (void*) e;
}

затем вызовите его с помощью:

package main

/*
#include "lib.h"
*/
import "C"

func main() {
  e := C.LoadEngine(C.CString("foobar")
  ...
}

у меня есть go1.12 windows/amd64
и mingw-w64-posix-seh

пробовал также mingw-w64-posix-sjlj, mingw-w64-win32-seh, mingw-w64-win32-sjlj, но результат тот же, или вообще не компилируется

скомпилировать его только с помощью go build и:

#cgo windows CFLAGS: -IC:/Engine/Inc
#cgo windows CPPFLAGS: -IC:/Engine/Inc
#cgo windows LDFLAGS: -LC:/Engine/Bin64 -lEngine -lEngineObj -lole32 -loleaut32 -luuid

На win8 работает нормально, но на win10+ не работает, если функция доходит до вызова GetEngineObject из dll, происходит сбой с:

Exception 0x40010006 0x1 0x8deb90 0x7ffbc9ada388
PC=0x7ffbc9ada388

runtime: unknown pc 0x7ffbc9ada388
stack: frame = {sp:0x8dea80, fp:0x0} stack=[0x0,0x8dfdf0)
00000000008de980:  0000000002000002  000000002a080321
00000000008de990:  0000000090000191  0000000000000321
00000000008de9a0:  0000000500000008  0000000500000000
00000000008de9b0:  feeefeeefeeefeee  00000000024c0150
00000000008de9c0:  0000000000000000  0000000000000000
00000000008de9d0:  00000000024c0000  00007ffbccb730ac
00000000008de9e0:  0000000002680000  00000000024c1e30
00000000008de9f0:  00000000026a2d90  00000000026ad480
00000000008dea00:  0000000000000df1  0000000000000000
00000000008dea10:  0000000000000df1  0000000000000df1
00000000008dea20:  0000000000001bf8  0000000000000000
00000000008dea30:  0000000090000191  0000000000000003
00000000008dea40:  0000bcc3daf1f4cb  00000000026a2d00
00000000008dea50:  0000000000000000  000002fffb442d78
00000000008dea60:  0000000000000000  00000000008dfb00
00000000008dea70:  0000000000000020  00007ffbc9ada388
00000000008dea80: <00000000024c0000  000000002fbe1490
00000000008dea90:  00000000008df970  00000000ffffffff
00000000008deaa0:  0000000040010006  0000000000000000
00000000008deab0:  00007ffbc9ada388  0000000000000002
00000000008deac0:  0000000000000001  00000000008deb90
00000000008dead0:  00000000001b0150  0000000000800000
00000000008deae0:  00000000026ad480  0000000000000000
00000000008deaf0:  00000000001b10b0  0000000000690000
00000000008deb00:  00000000024c0000  00007ffbccbbcafa
00000000008deb10:  00000000024c0000  00007ffbccb76ff8
00000000008deb20:  00000000026a2d90  00000000026a9c30
00000000008deb30:  0000000000000000  0000000000000001
00000000008deb40:  00002c98037a65f6  000000000000001f
00000000008deb50:  00000000026a9430  000000002fd8a367
00000000008deb60:  0000000000006000  00000000024c0000
00000000008deb70:  0000000000000df1  0000000000000000
runtime: unknown pc 0x7ffbc9ada388
stack: frame = {sp:0x8dea80, fp:0x0} stack=[0x0,0x8dfdf0)
00000000008de980:  0000000002000002  000000002a080321
00000000008de990:  0000000090000191  0000000000000321
00000000008de9a0:  0000000500000008  0000000500000000
00000000008de9b0:  feeefeeefeeefeee  00000000024c0150
00000000008de9c0:  0000000000000000  0000000000000000
00000000008de9d0:  00000000024c0000  00007ffbccb730ac
00000000008de9e0:  0000000002680000  00000000024c1e30
00000000008de9f0:  00000000026a2d90  00000000026ad480
00000000008dea00:  0000000000000df1  0000000000000000
00000000008dea10:  0000000000000df1  0000000000000df1
00000000008dea20:  0000000000001bf8  0000000000000000
00000000008dea30:  0000000090000191  0000000000000003
00000000008dea40:  0000bcc3daf1f4cb  00000000026a2d00
00000000008dea50:  0000000000000000  000002fffb442d78
00000000008dea60:  0000000000000000  00000000008dfb00
00000000008dea70:  0000000000000020  00007ffbc9ada388
00000000008dea80: <00000000024c0000  000000002fbe1490
00000000008dea90:  00000000008df970  00000000ffffffff
00000000008deaa0:  0000000040010006  0000000000000000
00000000008deab0:  00007ffbc9ada388  0000000000000002
00000000008deac0:  0000000000000001  00000000008deb90
00000000008dead0:  00000000001b0150  0000000000800000
00000000008deae0:  00000000026ad480  0000000000000000
00000000008deaf0:  00000000001b10b0  0000000000690000
00000000008deb00:  00000000024c0000  00007ffbccbbcafa
00000000008deb10:  00000000024c0000  00007ffbccb76ff8
00000000008deb20:  00000000026a2d90  00000000026a9c30
00000000008deb30:  0000000000000000  0000000000000001
00000000008deb40:  00002c98037a65f6  000000000000001f
00000000008deb50:  00000000026a9430  000000002fd8a367
00000000008deb60:  0000000000006000  00000000024c0000
00000000008deb70:  0000000000000df1  0000000000000000

goroutine 1 [syscall]:
path/to/package._Cfunc_LoadEngine(0x23a2c20, 0x0)
        _cgo_gotypes.go:518 +0x51
path/to/package.Load(0x4d05ad, 0x1d, 0x0, 0x0, 0x0)
        C:/Users/microo8/Documents/workspace/src/path/to/package/fre.go:55 +0x89
main.main()
        W:/Workspace/src/path/to/package/test/test.go:12 +0x41
rax     0x3e00003e
rbx     0x2fbe1490
rcx     0xfffffffffffffffe
rdi     0xffffffff
rsi     0x8df970
rbp     0x20
rsp     0x8dea80
r8      0x2fca2793
r9      0x3a0f4c0
r10     0x2fca2701
r11     0x26aadb0
r12     0x8dfb00
r13     0x0
r14     0x2fffb442d78
r15     0x0
rip     0x7ffbc9ada388
rflags  0x202
cs      0x33
fs      0x53
gs      0x2b

Я также пытался поймать исключение с помощью mingw __try1 и __except1, но все равно это не удается. Пробовал разные версии mingw, используя -ldflags = "-linkmode internal", но это не компилируется, и -ldflags = "-linkmode external" также делает это исключение.

Обновлено: также пытался вызвать функцию LoadEngine (из lib.h) из программы на C, и она отлично работает. Скомпилировал lib.cpp с g++ в lib.o. И связал его с test.c, где я только что вызвал функцию LoadEngine только из main. Так что, может быть, что-то не так, как go связывает библиотеку с cgo?

Источник

Hi. i have a problem, every time i trie to render with Vega PRO 17 the program chases.

i have tryed a lot of think.

if i «Disable» FileIOProxyStubx86.dll in X86 folder then i can render small easy projects. as an outtro.

but i am not able to load in biger projects.

Build information

VEGAS PRO 17 (452)

Win 10 (2004)

AMD Athlon X64 with 6 cord.

16 gb ram

Radeon RX560 Grafic Card. 4 gb

—-

Problem Description
   Application Name:    VEGAS Pro
   Application Version: Version 17.0 (Build 452)
   Problem:             Unmanaged Exception (0x40010006)
   Fault Module:        C:WINDOWSSYSTEM32ntdll.dll
   Fault Address:       0x00000000770CE3FA
   Fault Offset:        0x000000000008E3FA

Fault Process Details
   Process Path:        C:Program FilesVEGASVEGAS Pro 17.0x86FileIOSurrogate.exe
   Process Version:     Version 17.0 (Build 452)
   Process Description: File I/O surrogate (not visible)

—-

I dont have any pugnins install at the moment not even then that came with the program

i hope you can help.

Источник

Понравилась статья? Поделить с друзьями:
  • Ошибка принтер не подключен canon
  • Ошибка приложения код исключения 0x000006d9 photoshop
  • Ошибка принтер не отвечает canon что делать
  • Ошибка приложения класс не зарегистрирован
  • Ошибка принтер не отвечает canon pixma