I get the following error message in my output window :-
D3D11 ERROR: ID3D11Device::CreateDeferredContext: Creation of a Device with D3D11_CREATE_DEVICE_SINGLETHREADED prevents the creation of deferred contexts. [ STATE_CREATION ERROR #2097162: CREATEDEFERREDCONTEXT_SINGLETHREADED]
D3D11 ERROR: ID3D11Device::CreateDeferredContext: CreateDeferredContext returning DXGI_ERROR_INVALID_CALL, meaning the function can not be used. [ STATE_CREATION ERROR #2097164: CREATEDEFERREDCONTEXT_INVALID_CALL_RETURN]
But I never call that function and also I have a single threaded immediate
render context. This started happening abruptly.
Also, If i do a search for that function call then i get 0 hits in my entire solution.
Update 1 - The culprit seems to swap hain present because even if I don't create any shaders and buffers and just the context device and swapchain I still get this error
Update 2 - I have already tried the following -
Re-build the solution in debug and release mode.
Attaching the debugger by directly running the program on different graphic cards.
Re-installing DirectX.
Upgrading/Downgrading graphics and audio drivers.
going back to an old system restore point.
Re-installing Visual Studio
Related
I'm trying to use Sentry in my Expo managed workflow. I've followed the guide here, which includes calling Sentry.init() from App.tsx:
Sentry.init({
dsn: "https://blahblah#blahblah.ingest.sentry.io/blahblah",
enableInExpoDevelopment: true,
debug: true,
});
For some reason, calling Sentry.init() is leading to a crash on load. In debug mode (in expo go) I get the following error, which seems completely unrelated:
Objects are not valid as a React child (found: object with keys {_U, _V, _W, _X}).
This error is in a hook provided by expo-fonts, not in one of my own hooks. Additionally, when I remove the code calling Sentry.init() (or set enableInExpoDevelopment: false, the error goes away and everything works normally. Of course this means that I can't have Sentry in production which is a problem.
Does anyone know what could be causing this strange issue? I've double checked that my DSN and organization/project name are correct, and that I've followed the guide to a T.
I am attempting to port the DirectX12/XAML UWP template over to a C++-WinRT version... where EVERYTHING is done via C++-WinRT and I can turn off CX. I'm currently stuck on how to ResizeBuffers on the swapchain. Before resizing the buffers I have to release all the buffer references. In C++/CX ComPtr there is Reset() method to release reference of the renderTarget buffers, but in C++/winrt com_ptr no such Reset() method exists and if I set renderTarget to nullptr in order to release it, it throws an exception shown in the Screenshot below. And if I don't set the renderTarget to nullptr then exception is not thrown but the swapChain is also not resized.
Later I also tried it using the wrl::ComPtr and the Reset() method it is still throwing the same error. Does anyone know the correct way of resizing the swapChain in DirectX12?
Screenshot of the code and error
You can't use a "fail-fast" error handler like ThrowIfFailed for ResizeBuffers or Present. Both return meaningful failure codes at runtime you must handle.
Specifically both can return DXGI_ERROR_DEVICE_REMOVED or DXGI_ERROR_DEVICE_RESET and you need to handle it. In fact, in the UWP environment, you will see this happen at start up so you must handle it--some 'classic' Win32 desktop apps just ignore it and crash at weird times like when Windows Update updates a driver while the game is running.
For details on handling 'lost-device' (which is really 'device removed'), see DeviceResources .h / .cpp.
See also Microsoft Docs which is written for DirectX 11, but all the equivalent stuff has to happen for DirectX 12.
I'm using the latest build of DCEF3 and I'm trying to run ChromiumOSR programmatically in a console application. I naively tried this code at first:
Chromium := TChromiumOSR.Create(Self);
Chromium.OnLoadEnd := ChromiumLoadEnd;
Chromium.Load('http://google.com');
But it didn't work and raised an Access Violation. I then found this thread Getting errors creating ChromiumOSR programatically and modified my code accordingly:
Chromium := TChromiumOSR.Create(Self);
Chromium.OnLoadEnd := ChromiumLoadEnd;
Chromium.CreateBrowser;
Chromium.Load('http://google.com');
While I do not get any Access Violations anymore, my code is still not working. In fact, I plugged in a proxy and sniffed the connection: no requests are ever made to http://google.com. I do get the following error in my console application: ERROR - running without renderer sandbox. However, according to my searches on Google, the error can be "ignored" and the code should still work.
Of course, everything works fine if I create TChromiumOSR at design-time in a form application. However, I need to use it programmatically in a console application instead.
First I will describe the crash types I know about. Scroll down for the actual question. Note that I am only interested in crashes that are handled by Windows. Specific applications and frameworks sometimes have their own crash handlers (eg. Cygwin, the VCL, Java or .NET), which I will not discuss.
Dr Watson
On Windows XP, most unhandled "Structured Exceptions" such as access violations produce a Microsoft Application Error Reporting dialog (it was later renamed "Windows Error Reporting" but the executable is dwwin.exe and I will call it Dr Watson):
It is easily reproduced with *(char*)0=0;
FatalAppExit
Calling FatalAppExit() produces a MessageBox and Event Log entry, but no Dr Watson:
Stack overflow
On Windows XP a stack overflow causes the process to unceremoniously exit with no notification at all. (I think this was fixed starting with Vista)
It can be reproduced with main(){main();}
My question is, what causes one of these:
This dialog is owned by csrss.exe, and by the time I see it, the AcroRd32.exe process has exited.
It also writes an entry in the System Event Log (which a Dr Watson crash doesn't do):
I can reproduce the dialog and Event Log entry (but obviously not an actual crash), with this call to MessageBox:
MessageBox(
0,
"The exception unknown software exception (0xc0000409) occurred in the application at location 0x00404def.",
"AcroRd32.exe - Application Error",
MB_ICONSTOP | MB_SERVICE_NOTIFICATION);
I've ruled out Adobe Reader running as a service. It is version 11.0.08. The crash seems to happen sporadically when a Windows Explorer window with a PDF file selected becomes the active window.
Of course I'm not asking you to troubleshoot Adobe Reader for me, just how to produce an "Application Error" / "Application Popup" type of crash, preferably programmatically so I can understand what's going on.
This looks like the work of kernel32.UnhandledExceptionFilter. You might be able to trigger this error message with:
EXCEPTION_RECORD Rec = {
ExceptionCode : 0xc0000409, /* STATUS_STACK_BUFFER_OVERRUN */
ExceptionAddress : cast(void*) 0x404def,
};
CONTEXT Ctx;
RtlCaptureContext(&Ctx);
EXCEPTION_POINTERS Xcep = {
ExceptionRecord : &Rec,
ContextRecord : &Ctx,
};
UnhandledExceptionFilter(&Xcep);
However on Windows 7 that didn't do it for me, it just went straight to Dr Watson.
What does seem to work on W7 is this:
size_t[2] Params = [
0xc0000409, /* STATUS_STACK_BUFFER_OVERRUN */
0x404def, /* exception address */
];
int Response;
NtRaiseHardError(
0xc0000144 /* STATUS_UNHANDLED_EXCEPTION */ |
0x10000000 /* HARDERROR_OVERRIDE_ERRORMODE */,
Params.length,
0, /* UnicodeStringParameterMask */
Params.ptr,
2 /* OptionOkCancel */,
&Response
);
I know UnhandledExceptionFilter has this code somewhere, I just don't know what conditions it needs to take that code path. But you can just call NtRaiseHardError like this yourself.
Here's the result:
I don't use XP any more so you'll have to experiment yourself to see how these methods behave on XP, but hopefully this will give you a starting point.
The error dialog owned by CSRSS (which can also be programmatically triggered by a manual call to NtRaiseHardError, see this answer), is displayed on Windows when you have an unhandled exception. For all Win32 applications, a default exception handler for unhandled exceptions is set up by kernel32.dll, and this is this handler that does the job of either showing the Windows Error Reporting dialog, or showing the error dialog.
For the details, the open-source ReactOS project (which aim is to "re-create" Windows in an open-source way using clean-room RE) has similar code, that should help you knowing precisely in which conditions the error dialog appears: see the UnhandledExceptionFilter() function in dll/win32/kernel32/client/except.c.
I made a new OpenGL ES application, and without modifying anything, I ran the program. It runs, but I see these error messages:
Detected an attempt to call a symbol in system libraries that is not present on the iPhone:
open$UNIX2003 called from function _ZN4llvm12MemoryBuffer7getFileEPKcPSsx in image libLLVMContainer.dylib.
Detected an attempt to call a symbol in system libraries that is not present on the iPhone:
fstat$INODE64 called from function _ZN4llvm12MemoryBuffer7getFileEPKcPSsx in image libLLVMContainer.dylib.
Detected an attempt to call a symbol in system libraries that is not present on the iPhone:
mmap$UNIX2003 called from function _ZN4llvm3sys4Path14MapInFilePagesEiy in image libLLVMContainer.dylib.
Detected an attempt to call a symbol in system libraries that is not present on the iPhone:
close$UNIX2003 called from function _ZN4llvm12MemoryBuffer7getFileEPKcPSsx in image libLLVMContainer.dylib.
Detected an attempt to call a symbol in system libraries that is not present on the iPhone:
pthread_mutexattr_destroy$UNIX2003 called from function _ZN4llvm3sys5MutexC2Eb in image libLLVMContainer.dylib.
The program displays a colored box that moves up and down. Is this what it's supposed to do? What do these error messages mean?
I've been noticing the same. I'm running iOS sdk 4.1. But it only happens on the simulator.
From what I found at the apple forums, it seems to be a simulator bug. An Apple representative claimed that it was a bug on "their" end.
Here's the quote "This is a bug on our end, but as long as things are otherwise working for you, the logging can safely be ignored."