I'm running the VS project(which is developed with VS 2015) accompanied with Introduction to 3D Game Programming with DirectX 12 in VS 2019.
But it threw an exception with a HRESULT value of -2147024809 like this:
mCommandList->Close() failed in
E:\programs\cpp_codes\d3d12\Common\d3dApp.cpp;line 213; HRESULT:-2147024809
-2147024809 Indicates that the arguments are not correct. But as it is seen there is not any bit of argument passed to ID3D12GraphicsCommandList::Close() method, which confused me badly.
This line of code threw no exception months ago.
Another COM method threw similar exception in d3dApp.cpp, which is
ThrowIfFailed(md3dDevice->CreateCommittedResource(
&CD3DX12_HEAP_PROPERTIES(D3D12_HEAP_TYPE_DEFAULT),
D3D12_HEAP_FLAG_NONE,
&depthStencilDesc,
D3D12_RESOURCE_STATE_COMMON,
&optClear,
IID_PPV_ARGS(mDepthStencilBuffer.GetAddressOf()))); failed in
E:\programs\cpp_codes\d3d12\Common\d3dApp.cpp;line 203; HRESULT:-2147024809
But as long as I changed the fifth argument from &optClear into nullptr, this exception stops from showing up. Also, this invocation of CreateCommittedResource threw no exception months ago.
I think it is because there is a mismatch in clear color variable, try to set same clear color in all the clearColor variable usage ...
Comments below my question suggested that debug layer will best help in such condition. What I actually did was clicking Debug->Graphics->Start Graphics Debugging in the menu bar of Visual Studio 2019. And then, detailed debug information showed up in the output window of Visual Studio 2019, it ran D3D12 ERROR: ID3D12Device::CreateCommittedResource: pOptimizedClearValue must be NULL when D3D12_RESOURCE_DESC::Dimension is not D3D12_RESOURCE_DIMENSION_BUFFER and neither D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET nor D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL are set in D3D12_RESOURCE_DESC::Flags. [ STATE_CREATION ERROR #815: CREATERESOURCE_INVALIDCLEARVALUE].
So this is the point, because I had set D3D12_RESOURCE_FLAG_NONE in D3D12_RESOURCE_DESC::Flags.
It's no wonder that this exception stopped from being thrown by CreateCommittedResource after I passed nullptr to the fifth parameter of CreateCommittedResource. After I had set D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL, everything behaves well without any exception thrown.
And this is the code snippet ran into problem:
D3D12_RESOURCE_DESC depthStencilDesc;
depthStencilDesc.Dimension = D3D12_RESOURCE_DIMENSION_TEXTURE2D;
//Assignments to other members of depthStencilDesc
//This line caused the problem.
depthStencilDesc.Flags = D3D12_RESOURCE_FLAG_NONE;
D3D12_CLEAR_VALUE optClear;
//Assignments to the members of optClear
ThrowIfFailed(md3dDevice->CreateCommittedResource(
&CD3DX12_HEAP_PROPERTIES(D3D12_HEAP_TYPE_DEFAULT),
D3D12_HEAP_FLAG_NONE,
&depthStencilDesc,
D3D12_RESOURCE_STATE_COMMON,
&optClear,
IID_PPV_ARGS(mDepthStencilBuffer.GetAddressOf())));
Related
While debugging, I've always been able to see information about the exception once a catch block was entered even if my catch just looked like this:
catch
{
}
Since updating to Visual Studio 2017 though, I am only able to get exception information if I've actually declared a variable like so:
catch (Exception ex)
{
}
This is super annoying because there are a number of places where the exception is not declared (and normally does not need to be) but I do need to see what the exception is while debugging if there is one. How can I get the behavior back where it always shows me about the exception regardless of whether I've declared a variable for it or not?
In the locals window you should see a pseudo variable $exception that has the exception object for you to inspect. You can also add a watch expression for $exception in any of the watch windows.
Docs with more info and other pseudovariables is at: https://learn.microsoft.com/en-us/visualstudio/debugger/pseudovariables?view=vs-2017
Debugging with PyCharm (happens on multiple versions) I'm unable to correctly view some lists and dictionaries (other are presented correctly).
In the view window the object's name is presented with the message:
{list} Unable to get repr for <type 'list>
or
{dict} Unable to get repr for <type 'dict'>
An update:
In one of my attempts, I received the following message from the debugger (presented instead of the value of one of the list variable):
Unable to display children:Error resolving variables Traceback (most
recent call last): File "/Applications/PyCharm
CE.app/Contents/helpers/pydev/_pydevd_bundle/pydevd_comm.py", line
1004, in do_it
_typeName, valDict = pydevd_vars.resolve_compound_variable(self.thread_id, self.frame_id,
self.scope, self.attributes) TypeError: 'NoneType' object is not
iterable
I'll appreciate any idea as for what may cause this behavior?
Thanks!
It turned out the problem is due to usage of rpyc.py: The process I was debugging was called through rpyc and while I was debugging it, the calling process received a timeout on the rpyc connection.
I think that this caused variables, passed through rpc to lose integrity so the debugger couldn't present them correctly.
The solution was to downgrade rpyc.py to version 3.3.0 (I was on 3.4.2).
My colleague, Nurit Izraelov, correctly suggested the rpyc.py version may be the blame.
Thanks all!
It happened to me sometimes and what caused the behaviour was that some MyClass triggered an exception on its str method.
In such a case, PyCharm debugger only showed
some_object = {MyClass} Unable to get repr for <class 'my_app.models.MyClass'>
So what I did to confirm the origin was to watch repr(some_object) in the Watches section of the debugger. And there it gave me an explicit error message:
{TypeError}%d format: a number is required, not NoneType
Which helped me trace back to the origin.
I appreciate this is not a generic answer, but just a complement to Fabio's.
Probably some custom class of yours has a bad __repr__ or __str__ in it and the debugger is unable to print it.
You can probably use a shell at that point to know which elements are actually inside such a dict or list (and see which object has the faulty __repr__ or __str__).
Extending the scope of the problem rather than adding an answer - all the other suggestions are what I do normally to get this working.
Could it be a race condition?
For me it appears to be something weird. In the Variables pane I can see correct representation for theObject, repr(theObject) and even [theObject] but if I set a variable in my code thus a = theObject or b = [theObject] then I get the "Unable to get repr for <class 'list'>" message.
theObject in this case is an instance of a subclassed D lang struct wrapped with autowrap.
Currently when an exception is thrown from within my Unity script while using my HoloLens the Debug Output in Visual Studio shows the stack trace without the line numbers.
How do I get the line numbers along with the stack trace? I'd be fine with it being logged somewhere else other than the Debug Output.
Here's some example output in Visual Studio:
Exception thrown: 'System.NullReferenceException' in Assembly-CSharp.dll
NullReferenceException: Object reference not set to an instance of an object.
at NewBehaviourScript.Update()
at NewBehaviourScript.$Invoke6Update(Int64 instance, Int64* args)
at UnityEngine.Internal.$MethodUtility.InvokeMethod(Int64 instance, Int64* args, IntPtr method)
(Filename: <Unknown> Line: 0)
And the corresponding Unity script (I made a Cube and attached a NewBehaviourScript component):
public class NewBehaviourScript : MonoBehaviour {
// Update is called once per frame
void Update ()
{
object a = null;
a.GetType();
}
}
I tried changing the build from Release to Debug doesn't give the line numbers.
I tried googling, and it looks like it's not showing the line numbers for others, as well: http://answers.unity3d.com/questions/1315985/null-reference-in-line-0.html
I tried asking on Microsoft's forums, but didn't receive any useful replies.
I don't think you would get the line number since it does not exist anymore. You get it in Unity editor because you are not running a full build of the application so Unity still has access to the non-compiled code. When you run on the device, it sends debug commands to the VS console about the printing and the errors but all the code is binary at that point, so there is no reason nor possibility to provide a line number.
Actually this is not specific to Hololens, but you would get the same in Android or iOS. Once build, the code is no longer the same, it does not even match one to one as the compiler performs optimizations.
What you can do is placed Debug commands to see where it happens.
public class NewBehaviourScript : MonoBehaviour {
// Update is called once per frame
void Update ()
{
object a = null;
#if DEBUG
if(a == null)
{
Debug.Log("[NewBehaviourScript] Running update with null a object");
}
#endif
a.GetType();
Debug.Log("[NewBeahviourScript] if this line prints, method did not crash");
}
}
In this example, you can use the DEBUG macros if you would have code running only for debug purpose. This way you can easily exclude it on export. The second call for Debug is not required in the macro since the build process will discard it when you set the build to Release or Master.
I have this UWP app that uses a project (UWP class library) which itself uses EF7 and SQLite.
I tried to build the app in the Release mode using .Net native tool chain, the build completes successfully (after a good long time, and after eating as much memory as it can), but the application crashes just after leaving the splash screen.
After following some advice on SO I tried the .Net native with Debug mode, the build finishes just like in the Release mode, but I get many errors on the output window and it is the same scenario as this one UWP - .NET Native tool chain compilation error
I followed #Matt Whilden advice, and I got rid of those errors, then tried again.
This time I got hit by this famous MissingMetadataException :
The output window shows this :
Exception thrown: 'System.AggregateException' in System.Private.Threading.dll
Exception thrown: 'System.ArgumentException' in System.Linq.Expressions.dll
Exception thrown: 'System.ArgumentException' in System.Linq.Expressions.dll
Exception thrown: 'System.ArgumentException' in System.Linq.Expressions.dll
The thread 0x2a30 has exited with code 0 (0x0).
Exception thrown: 'System.Reflection.MissingMetadataException' in System.Private.Reflection.Core.dll
Additional information: 'Microsoft.Extensions.Caching.Memory.MemoryCacheOptions' is missing
metadata. For more information, please visit
http://go.microsoft.com/fwlink/?LinkID=392859
I tried to follow my code, during execution and I found out that it is caused by the first ever call to a DbSet table from my DbContext
public long GetLastTimeStamp()
{
//-----> Here is the line causing the error
var sortedArticles = DbContext.Articles.OrderByDescending(article => article.ArticlePubDate).ToList();
if (sortedArticles != null && sortedArticles.Count != 0)
{
DateTime epoch = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Local);
TimeSpan elapsedTime = sortedArticles.First().ArticlePubDate - epoch;
return (long)elapsedTime.TotalSeconds;
}
else
{
return 0;
}
}
This method above is called inside an Async method, just to know.
I tried, desperately, to call .ToList() by doing :
var sortedArticles = DbContext.Articles.ToList().OrderByDescending(article => article.ArticlePubDate).ToList();
But still get the same error.
This is really frustrating, I don't know how to solve this problem, not sure what and how I should change the Default.rd.xml, any one can help telling me how to achieve this build correctly ?
Please try to add type 'Microsoft.Extensions.Caching.Memory.MemoryCacheOptions' in Default.rd.xml (already present in your project).
cf. https://blogs.msdn.microsoft.com/dotnet/2014/05/21/net-native-deep-dive-help-i-hit-a-missingmetadataexception/
For example:
<?xml version="1.0" encoding="utf-8"?>
<Directives xmlns="http://schemas.microsoft.com/netfx/2013/01/metadata">
<Application>
<Type Name="Microsoft.Extensions.Caching.Memory.MemoryCacheOptions" Dynamic="Required All" />
</Application>
</Directives>
We have using Moq for two month now. However there is a problem which can not solve somehow.
In visual studio all tests succeeded just fine. On the build server there are several tests which failed. What they have in common is, that they use the "raise" method to throw an event. Our build server tests obfuscated what is good to find obfuscation errors. Every "normal" expectation like "Setup(something).Returns(something)" works. Only the raise event fails. the stacktrace looks like the following:
MESSAGE:
Test method Ade.Graphic.Presenter.Test.RoutingEngineTest.TestRouteOverLadderLinesWithFbd threw exception:
System.ArgumentException: Could not locate event for attach or detach method Void ᜀ(ᦜ[ᢈ]).
+++++++++++++++++++
STACK TRACE:
bei Moq.Extensions.GetEvent[TMock](Action`1 eventExpression, TMock mock)
bei Moq.Mock`1.Raise(Action`1 eventExpression, EventArgs args)
bei Ade.Graphic.Presenter.Test.RoutingEngineTest.TestRouteOverLadderLinesWithFbd()
The code for this is:
documentEventHandler.Raise(stub => stub.DocumentChanged += null,
new DocumentChangeEventArgs(DocumentChangeTypes.ViewUpdate));
We have no idea what is the difference between the code above and this
eventHandler.SetupGet(stub => stub.DocumentChangeNotify).Returns(documentEventHandler.Object);
because this code works fine.
Does anyone had the same problem or at least can tell what the difference is?
The error comes probably (not sure as not tested) from the fact that events (i.e. DocumentChanged) are actually generated as 2 accessors: add_DocumentChanged and remove_DocumentChanged . This is similar to the properties that have the get and set accessors.
What the obfuscator did most probably is rename this add_DocumentChanged and remove_DocumentChanged. However, looking at the moq source code, I can see that moq relies on the events accessor keeping the same name:
var ev = addRemove.DeclaringType.GetEvent(
addRemove.Name.Replace("add_", string.Empty).Replace("remove_", string.Empty));
ev == null in this case, which raises an error.
In your second examples, you're using delegates which are not broken down into add_ and remove_ accessors.
You're probably better off not obfuscating events.