I use clBuildProgram to build a program for devices list,containing 10 devices
it fails.I checked that the failure happens due to the compilation problem with one device only.I still want to use clGetProgramInfo to extract info for the devices for which compilation was OK.
can I do it?(while still performing clBuildProgram for entire device list)
thanks
Related
Example: Here's the debug log for CreateGraphicsPipelineState, it tells me what went wrong:
D3D12 ERROR: ID3D12Device::CreateGraphicsPipelineState: Root Signature doesn't match Vertex Shader: Shader CBV descriptor range (RegisterSpace=0, NumDescriptors=1, BaseShaderRegister=0) is not fully bound in root signature
However, a call to windows FormatMessage(MESSAGE_FROM_SYSTEM...) will return this for the exact same error:
The parameter is incorrect.
The first is obviously far more useful...
We used to have dxerr.lib, and we have source for dxerr.cpp in DXUT. But this doesn't cover DX12. I can't see any way for a shader-tool to retrieve the error and present it to the user from the API.
This can be done with the ID3D12InfoQueue interface, as documented here:
https://learn.microsoft.com/en-us/windows/win32/api/d3d12sdklayers/nn-d3d12sdklayers-id3d12infoqueue
As far as I can tell it's currently not possible to set a callback, which means that you'll need to explicitly query for feedback.
There are two different sources of error/status information involved here. The error code you have returned from the API call is E_INVALIDARG and you obtained a good string for it. This is the status code from the API.
The descriptive message you see in debug output is emitted by Direct3D 12 debug layer, which you loaded during API initialization. It is, generally speaking, an optional component and might be not available in the system while the API itself is available.
To intercept debug output programmatically you can either
utilize this trick: Capture OutputDebugString output
or, attach as a debugger to your application and process debug output event recording the contents
I am trying to get Vulkan running under X11.
I have (apparently) successfully created an instance, device and surface, and several calls relating to the surface also succeed, and even return reasonable values (for example vkGetPhysicalDeviceSurfaceFormatsKHR returns two formats). However, when I call vkGetPhysicalDeviceSurfaceCapabilitiesKHR, I get the following:
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 14 (X_GetGeometry)
Resource id in failed request: 0x5800009
Serial number of failed request: 42
Current serial number in output stream: 42
The X11 Window is 0x5800009, as referenced in the error. I am using Vulkan SDK 1.0.5, and Nvidia 364.12 drivers (if that is relevant).
On the hunch that Vulkan was querying something about the Window that had not yet been created, I put a XSync(<display>, false) call before this one, and that seems to have solved the issue.
I am not sure whether this is required for proper operation (I am not an X11 expert), or whether this is an issue with Vulkan itself. If somebody has a better explanation, I would love to hear it.
I had the same error on Linux with XCB and I resolved it (with the help of MuertoExcobito's answer) by calling xcb_flush after the window creation.
I came across that same error when I bound ::XDisplay to VkSwapchainCreateInfoKHR.dpy before a window handle was actually created. So long as I keep that structure updated during resize events (with both .dpy and .window), everything continues to work fine.
This touches on some already-answered questions, so feel free to duplicate away, but chances are I've already read them and am not satisfied.
There are 2 drivers on my system (located in C:\Windows\System32\drivers) called pefndis.sys and wfpcapture.sys. I am 100% sure pefndis.sys is a kernel driver and 99.9% sure wfpcature.sys is as well. These are 3rd party drivers installed by Mircosoft's Message Analyzer. I have discovered pefndis.sys is used to capture data on the wire and wfpcapture.sys is used to capture data above the network layer (ie, this will capture loopback traffic). I have no documentation, header files, etc, for these drivers as there was no intention of Microsoft for these drivers to be used for custom solutions as I would like to do. It just so happens I've identified wfpcapture.sys as performing the exact tasks I want, and I'd love to tap into what it can do; this seems so much more reasonable than spending the time and pain of implementing my own driver. However, my efforts have failed.
This is what I've done: I have some simple c++ code here:
void Provider::InitDriver()
{
HANDLE wfpHandle = NULL;
DWORD lastError = 0;
LPCTSTR wfpName = L"\\\\.\\wfpcapture";
LPCTSTR pefName = L"\\\\.\\pefndis";
wfpHandle = CreateFile(
wfpName,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
lastError = GetLastError();
CloseHandle(wfpHandle);
}
When I run CreateFile with wfpName, I get an invalid handle and lastError==2 meaning the file cannot be found. When I run CreateFile with pefName, I get a valid handle and lastError==0. Upon further investigation, most of my randomly-picked .sys files from the drivers folder produce invalid handles with error codes of 2. Occasionally I'd get an error code of 5 (Access Denied, which also seems odd since I'm running everything as administrator). Does anyone have an explanation why I cannot get a handle to wfpcapture.sys? I brought up the pefndis.sys driver because it was installed by the same program as wfpcapture.sys, and I can clearly get a handle to that, so all my strings are formatted correctly, and both files are in the same directory. I came across this post yesterday which told me IoCreateSymbolicLink can be used in the driver code to give the driver another alias. If I'm using the wrong alias, does that explain why so many .sys files return FILE_NOT_FOUND errors when I try to get handles to them?
I've tried to do some more research on the file using IL DASM (no luck, this is native code), DUMPBIN, WinObj, and DependencyWalker.
DUMPBIN /EXPORTS [...]wfpcapture.sys returns no exports. I find this extremely odd. These answers suggest .DLLs without exports are simply resources or the code is obfuscated. I am almost certain wfpcapture.sys does not just contain resources. Is obfuscation the most reasonable explanation.. any other ideas why it doesn't have any exports?
I could not find wfpcapture in WinObj anywhere. I located pefndis in Device\. Where is wfpcapture? It doesn't actually talk to a device, so that makes sense, but it is still a driver, correct? Do drivers need to register with Windows in some way before CreateFile can find them?
DependencyWalker verified what DUMPBIN told me, I think .. no exports. I have no idea how Message Analyzer (or anything else down its dependency stack) is actually talking to it.
Just a bit more background for a complete picture... wfpcapture.sys is an ETW Provider that taps into Microsoft's WFP architecture (used for firewall and IDS applications) to sniff packets above the network layer. I want code that "activates" wfpcapture.sys and then sits back and collects the events (packet captures) that wfpcapture publishes. It's this activation part that I can't figure out. If I setup Message Analyzer to start capturing localhost traffic, then turn on the part of my code that captures the events (using StartTrace(...) and EnableTraceEx2(...)), that works just fine. I am just dying to know how Message Analyzer is talking to wfpcapture.sys and what it's saying in order to get it to cooperate and start publishing events. Another fun fact: When I start a trace in Message Analyzer and do sc query wfpcapture, it tells me the service (here it is identified as a kernel driver) is running. When I stop the trace, the query tells me the service is stopped. If I manually sc start wfpcapture and verify the service is running,, and then run my event capturing code, I get nothing. This tells me Message Analyzer must be sending something to wfpcapture.sys to get it activated and publishing. My plan that spawned this whole thing was to get a handle to driver and start sending it control codes via DeviceIoControl to glean some knowledge on how it worked. I have also seen some very strong evidence that Message Analyzer is passing filter masks to the driver.
Am I completely wasting my time here? That driver is not meant for my consumption, and poking and prodding it to learn about it may be a long shot, but I'm certain it does exactly what I need and I've never written a driver in my life; trying to do that seems foolish when this is sitting right here. Message Analyzer is free, I'm not trying to steal software. Could there possibly be some DRM associated with the driver that's boxing me out? I'd love to hear the thoughts of anyone out there who has Windows driver experience.
Ok, lot of questions there, hope this doesn't get flagged as too broad.
I'm playing around with abstracting Windows, Linux, and Mac File IO calls into macros (to avoid C runtime, so no fopen, fclose, etc...). I've actually got quite a bit working but I've run into a stumbling block.
I'm trying to boil down all of the possible errors that could be thrown by each of these platforms into a subset of common ones: Not Found, Exists, Invalid Access, etc.
Linux is obviously well document, Mac even has the most common ones, but Windows does not specify which errors are thrown for its native File I/O functions. We obviously need to use GetLastError(), but I could not find a reference to what the possible values would be.
How about this?
I'm writing a Windows application and using the CreatFile() API. I'd like to handle any errors as gracefully as I can, and perhaps recover from said error instead of telling the user "Crap! Can't do that." But the MSDN docs don't list the possible error codes that could be generated.
Does anyone have a reference to the possible error codes that Windows File functions may generate, specifically (for now) CreateFile()?
Windows supports installable file systems. Microsoft cannot possibly predict what kind of errors a 3rd party file system driver is going to generate so does not make any attempt to promise a strict sub-set of possible error codes.
So yes, you really do have to use GetLastError(). The FormatMessage() function is available to generate a readable string for the error code. In general, the user will get a decent error message that helps him diagnose the root cause. It isn't quite specific enough to tell that an earthquake in Chile severed an undersea communication cable but it will certainly help him to start looking at networking problems for example. You can use the CRT wrappers as well, but with the inevitable loss of specificity. That might be a service call that you have to handle instead of the user's IT staff.
to avoid C runtime
You're reinventing the wheel. C runtime was created so people could write platform-independent programs that (theorietcally) would compile anywhere, as long as you aren't using something platform-specific.
Right now, you're doing the same thing.
I'd advise to stop doing that and either use standard C file function, or cross-platform framework that support several platform. You could use either Boost or Qt 4.
Regarding your question
Does anyone have a reference to the possible error codes that Windows File functions may generate,
WinAPI documentation is available on MSDN and you should read it.
CreateFile
GetLastError
SystemErrorCodes
Does anyone have a reference to the possible error codes that Windows File functions may generate
Because CreateFile doesn't only deal with "files" (it also works with directories, pipes, physical devices, etc), you should assume that it can generate any operating system code that exists. According to msdn, there are 16000 codes total. Moral of the story: if you want to generate human-readable message, use FormatMessage. If documentation doesn't list possible error codes (for CreateFile), it automatically means, that CreateFile can produce any error code that exists.
As SigTerm stated, there's no definitive list of system error codes associated with CreateFile. Your best bet is searching for the keyword "ERROR" in the CreateFileA/CreateFileW documentation.
Otherwise, there's always web search engine. A quick DuckDuckGo search of "CreateFile" and "Error" reveals a slew of errors and error codes
You should also consult Microsoft's lengthy lists of System Error Codes and Win32 Error Codes.
Excerpts from CreateFileA/CreateFileW Documentation
param: dwShareMode
You cannot request a sharing mode that conflicts with the access mode that is specified in an existing request that has an open handle. CreateFile would fail and the GetLastError function would return ERROR_SHARING_VIOLATION (32).
param: dwCreationDisposition
CREATE_ALWAYS
If the specified file exists and is writable, the function overwrites the file, the function succeeds, and last-error code is set to ERROR_ALREADY_EXISTS (183).
CREATE_NEW
If the specified file exists, the function fails and the last-error code is set to ERROR_FILE_EXISTS (80).
OPEN_ALWAYS
If the specified file exists, the function succeeds and the last-error code is set to ERROR_ALREADY_EXISTS (183).
OPEN_EXISTING
If the specified file or device does not exist, the function fails and the last-error code is set to ERROR_FILE_NOT_FOUND (2).
TRUNCATE_EXISTING
If the specified file does not exist, the function fails and the last-error code is set to ERROR_FILE_NOT_FOUND (2).
Files
If you call CreateFile on a file that is pending deletion as a result of a previous call to DeleteFile, the function fails. The operating system delays file deletion until all handles to the file are closed. GetLastError returns ERROR_ACCESS_DENIED.
If CREATE_ALWAYS and FILE_ATTRIBUTE_NORMAL are specified, CreateFile fails and sets the last error to ERROR_ACCESS_DENIED if the file exists and has the FILE_ATTRIBUTE_HIDDEN or FILE_ATTRIBUTE_SYSTEM attribute. To avoid the error, specify the same attributes as the existing file.
When an application creates a file across a network, it is better to use GENERIC_READ | GENERIC_WRITE for dwDesiredAccess than to use GENERIC_WRITE alone. The resulting code is faster, because the redirector can use the cache manager and send fewer SMBs with more data. This combination also avoids an issue where writing to a file across a network can occasionally return ERROR_ACCESS_DENIED.
Consoles
If lpFileName is indeterminate "CON" and dwDesiredAccess is GENERIC_READ | GENERIC_WRITE, CreateFile fails; GetLastError returns ERROR_FILE_NOT_FOUND.
"CON" and GENERIC_READ implies a console handle for input.
"CON" and "GENERIC_WRITE` implies a console handle for output.
Pipes
If the CreateNamedPipe function was not successfully called on the server prior to this operation, a pipe will not exist and CreateFile will fail with ERROR_FILE_NOT_FOUND.
If there is at least one active pipe instance but there are no available listener pipes on the server, which means all pipe instances are currently connected, CreateFile fails with ERROR_PIPE_BUSY.
Various errors from across the internet
ERROR_INVALID_FUNCTION (1)
ERROR_FILE_NOT_FOUND (2)
ERROR_PATH_NOT_FOUND (3)
ERROR_ACCESS_DENIED (5)
ERROR_GEN_FAILURE (31) - A device attached to the system is not functioning. This can also occur when working with network devices e.g. virtual network adapters
ERROR_SHARING_VIOLATION (32) - The process cannot access the file because it is being used by another process.
ERROR_INVALID_PARAMETER (87) - "An application must meet certain requirements when working with files that are opened with FILE_FLAG_NO_BUFFERING: File access must begin at byte offsets within a file that are integer multiples of the volume sector size. File access must be for numbers of bytes that are integer multiples of the volume sector size. For example, if the sector size is 512 bytes, an application can request reads and writes of 512, 1024, 1536, or 2048 bytes, but not of 335, 981, or 7171 bytes. Buffer addresses for read and write operations should be sector aligned, which means aligned on addresses in memory that are integer multiples of the volume sector size. Depending on the disk, this requirement may not be enforced."
ERROR_CALL_NOT_IMPLEMENTED (120) - using P/Invoke and calling to coredll.dll for Windows Pocket PC
ERROR_INVALID_NAME (123)
ERROR_FILE_SYSTEM_VIRTUALIZATION_INVALID_OPERATION (181)
ERROR_FILE_TOO_LARGE (223)
ERROR_CONNECTION_COUNT_LIMIT (1238)
ERROR_MUTUAL_AUTH_FAILED (1397) - network auth e.g. serial COM port over Bluetooth
ERROR_NO_SYSTEM_RESOURCES (1450) - e.g. working with Serial Ports
My application is reading/writing data to a removable media (USB DOK) in the background. The problem is that when the USB is removed while the app is working, the computer pops up an error message:
Wrong Volume
The wrong volume is in the drive. Please insert volume into drive E:.
Cancel Try Again Continue
This happens during operations such as GetFileSize, ReadFile. Obviously, since the app is supposed to work in the background, I would like to suppress those messages and fail silently.
BTW - It seems that the process giving those message is not my process, but CSRSS.EXE (although the cause is definitely the operation from my process).
One direction I am considering is switching to NtQueryInformationFile, NtReadFile, etc., but I'd rather not...
Thanks
Try calling:
SetErrorMode(SEM_NOOPENFILEERRORBOX);
At the beginning of your main function.
From the documentation:
The system does not display a message box when it fails to find a file. Instead, the error is returned to the calling process.
I suggest you properly disconnect your hardware using the icon in the windows system tray so that it's not being accessed when you pull it out of the drive. Or at least exit your ap first.