-
January 22nd, 2017, 01:29 PM
#16
Re: general question - detecting CPU and Windows version
At then end of the day, you have an app that crashes on a particular OS after a motherboard has been changed. My money is on the idea that the wrong or incompatible drivers are the cause.
It could be that the drivers you have for XP don't work with your new motherboard (because of the newness of the mb). XP is 16 years old and that's pretty old to expect driver support on newer hardware.
At any rate, as a test, put in an empty hard drive, install XP, and install the software you are interested in and see if you run into the same issues. My expectation is you'll see the same trouble. If not, it will be at least useful to know that XP can work with the new mb and your software. From there you can further diagnose, by matching the driver versions on the fresh install, and so on to help narrow down the issue.
Last edited by Arjay; January 22nd, 2017 at 01:31 PM.
-
January 24th, 2017, 02:41 PM
#17
Re: general question - detecting CPU and Windows version
There is one crash I can easily recreate at will. This time I have installed Windbg as the post-mortem debugger.
The crash clearly shows an AVX instruction failing, when this should not be executed in XP,
since it's unsupported in XP. It shows the the instruction VPSUBUSB being issued.
This crash, in FFmpeg, must mean the the code that determines if a particular feature is supported
or not has failed
Once again, this crash only occurs when XP is booted from the Windows 10 Boot manager
Further thoughts ?
-
January 26th, 2017, 05:09 PM
#18
Re: general question - detecting CPU and Windows version
Here's an update, but first of all thanks for all your comments and suggestions
One of the programmers assigned to the Firefox thread that tracks this crash (I'm not the only one experiencing it)
responded to me when I woke the thread up with a post after three months of inactivity.
I happened to mention that I'd only seen it crash when booting XP through the Windows 10 boor manager.
I'm not sure if he looked at the dump or recreated it under the debugger, but he mentioned OSXSAVE and OSFXSR
being on in CR4. A brief discussion occurred via email where there was some mention as to whether AMD FX errata
was to blame or whether Windows 10 Bootmgr / Windload did not set the relevant bit(s) off when an NTLDR based system
was selected
It might be useful to see if somebody could recreate the scenario using a relatively modern Intel CPU.
Something that supports the avx instructions and capable of running Windows XP
I'm now able to recreate the crash with WinDbg, I only wish I was more experienced
with this tool and the PC environment.
(I used to do this kind of debugging with IBM mainframes 15 years ago)
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|