Ah, so it's essentially a recursive Reset call. My guess would be that we don't want to allow that, but it requires some tests on native win32 to verify. You could try returning WINED3DERR_INVALIDCALL when Reset gets called from inside another Reset call, to see how the application reacts to that.
This also raises another question regarding the window handling in wined3d: Are we allowed / supposed to modify the window size and position of the destination window the app supplies like this? A lot of apps seem to need that, otherwise the rendering is placed incorrectly or not visible because the window is hidden. However, it could be that Windows somehow renders correctly without changing the Window's properties.
So the SetWindowPos() call in Reset() might be the wrong thing here. It is not entirely unexpected that the app calls Reset when it receives a Window position / size change. If the Window size changes, the app is supposed to reset the D3D device, otherwise the rendering output is stretched in Present(which can look kinda ugly)