well I actually suspected something slightly different actually, not already at fence creation.
if your code does not go the assert path, i.e your result == VK_SUCCESS I’m somewhat baffled.
as others have remarked the api trace you published does not hint at an error there either.
how and where is m_VkInFlight declared, “seems” to be a member of the class but could you show that bit of code
Absolutely, I’m also baffled lol. They’re private static member variables, and declared before any functions roll out. Also wanted to add, just in case you happen to ask this next, its declared in the header file, then initialized in the screenshot below.
It’s not clear to me how something initialized to a VK_NULL_HANDLE(3) can have a memory address 0xcccccccccccccccc.
Specifically, I can not reason my way through how this should be the case after vkCreateFence with return value VK_SUCCESS and no validation errors.
If the code was out there publicly available I would try and run it but, as is, I feel there is something missing.
All I can recommend is to debug as much as you can up to the step that you believe is the issue. It’s perhaps tedious but probably unavoidable 
Yeah unfortunately, I have been double checking everything for the past few days. Not sure as to how fence would be this way either. The semaphores seem to have the address as well. These, as far as I am aware, are the only variables that are 0xcccccccccccccccc. Of course now I will be checking after every create function to see if this is the case. Not sure how errors have not been brought up before hand if it is something else though. Very much witchcraft to me at the moment.
Well, something really weird happened. Its not fixed, so I don’t wanna give any wrong impressions, but they are now being recognized as legitimate memory address’s. But as I said, didn’t solve anything. Just to be clear how I got that to not happen anymore, its black magic, I just went to VK_NULL_HANDLE and switched it to NULL and it all went through with a system initialization address. I then changed it back to VK_NULL_HANDLE and still operates normally. Not sure at all, as to what that did for it, but yeah. Could just be a weird visual studio bug.
Could any of this be caused by passing a VkPhysicalDevice and VkSurfaceKHR handle to another file through a get function? I had done this to compartmentalize the initialization and have just rendering done in another file.
Could any of this be caused by passing a
VkPhysicalDeviceandVkSurfaceKHRhandle to another file through a get function?
Not under normal circumstances.
As I was trying to say, these piecemeal information drops, speculations, and desperate trial-and-error attempts are unlikely to get us anywhere in reasonable time.
It will likely be something mundane as it always is (uninitialized variable, use-past-free, …), and not some arcane mystery worth spending a week on. Only question is where this is located, and for that it is necessary to see the whole picture. Just show the whole code.
I still think API dump would also be advantageous, as it shows raw calls and values, and not speculations and assumptions. The previously posted dump is from something else that doesn’t crash (it ends with vkDestroyDebugUtilsMessengerEXT, which would be in proper app teardown). You would simply get the dump by:
vkconfig
cmd
set VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_api_dumpyourapp.exe > apidump.txtstd::cout.I am doing what you told me to do with the instructions at the bottom. I do not get anything outputted into the apidump.txt. Though it does get created. Things seem to only really work with layers if I use it through the vkconfig app. It must be open and then I can run whatever program I have in the active apps. The fact I can’t even get simple layers to work through your instructions bothers me. I guess I’m just an idiot, sorry. Odd thing is that it does in fact give some output for a test case that I try, when running only my app with the debug messenger setup internally, just not much at all.
Just to add, the previous api dump I provided was truly the application that crashes. It just does not show it, I don’t know how else to explain it. It hits the exception, I end the debug session and check the file and its what was recorded. Fresh data that was not there before. This is when having the vkconfig app open because its the only time the dump actually works. Any other suggested way does not seem to operated as advertised on my machine.
I set the instance layers through cmd like you suggested and nothing happens except the text file is created with no output in it whatsoever. Also, I am not trying to piecemeal info to you, I am just stating what I have tried and any differences that have occurred. Not trying to be annoying, if I am, again I am sorry. I’ll stop posting here until I come to some sort of working conclusion myself. I just am not sure why this would not be caught through all of the creation results.
I did find that when running the Frame Capture configuration, it outputs
ERROR: vkWaitForFences: Invalid device [VUID-vkWaitForFences-device-parameter]
So at least its telling me, now. I’ll just go off on my own looking for the cause. Hopefully I’ll have good news one day!
Alright, I finally found my mistake and I am quite embarrassed, I must say. Turns out, my Vulkan and render initialization object were calling their destructor almost immediately after setting up all resources. So that is why the api dump showed everything seemingly properly tearing down. It was literally destroying the resource handles after creating them. I just replaced my Vulkan and render object creation with a pointer to the objects instead so I could explicitly invoke the destructor when ready. All works now! Sorry for the confusion and trouble I put you all through.
Yea, I warned you it gonna be some of those trivial mistakes. Always is.
Important skill is to learn how not to spend days on these kinds of bugs…