Nox

I thought about writing a script for this for a few days, but decided that researching how to hack this stuff together to download the ISO automatically was not worth the effort, it only takes 5 minutes to mount and extract the folder manually anyways, so I wrote this how-to instead.

Get WinMetadata files (directly from Microsoft) without installing Windows Download the Windows 11 Disk Image (ISO) from Microsoft [6.33 GiB (6.797.694.976 Byte)]. Mount the ISO (with Disk Image Mounter for example) Navigate to `sources` and open `install.wim` with a capable archive manager software (e.g. PeaZip (Flathub)) Navigate to one of these numbered folders (They are the different Editions, `10` is Windows 11 Pro for Workstations for example) (I have not checked if the WinMetadata-files are the same in every version of Windows, so it might be best to choose a Pro version.) Navigate to `Windows/System32` Select the `WinMetadata` and extract it ("Right click" -> "Extract To...") Profit!

This is a brad new Windows 11 installation, and this is my first driver crash - caused by Affinity Photo - on it: Affinity Crash reports: 7230f4d5-ad6a-4b63-a4b0-18233e102d3e.dmp attachment_Log.txt 51fc2540-c8fe-4435-9f29-4da12db60d33.dmp attachment_Log.txt 1cc57f41-00be-4562-aaa3-e6c3801d517a.dmp attachment_Log.txt <-OpenCL Errors AMD crash report: AMD Bug Reporting Form Submitted Data 20230203T231319.zip 🔑 I hope that the addition of the AMD crash report will provide additional helpful resources to resolve this issue. it crashed multiple times on the same document, description of the said document: dimensions: 1920x1080 Layers: Group Artistic Text Linked .afdesign document (700x700 vector art) Solid Fill Steps leading to the crashes: I duplicated the Group [Ctrl + J]. Blurred the lower Group with a 100px radius Gaussian Blur Live Filter. Set the blurred Group's layer opacity to 80%. Added an Outer Shadow Layer Effect to the upper Group. <- first crash happened here Blend mode: Normal Opacity: 30% Radius: 10px Offset: 0, Intensity: 0, Colour: black, Angle 270°, [x] Fill knocks out shadow Zoomed and panned the View Duplicated the bottom Solid Fill layer. <- second crash happened here Changed the upper Fill Layer to Radial. Changed the Fill Layer Gradient position. Changed the Gradient colours. Tried to change the Gradient's position. <- third crash happened here Other opened application windows: Firefox on the second monitor with a lot of tabs open, but the active one was the website of the project I'm working on. Steam - viewing a Steam user's profile (has these animated video backgrounds), on the main monitor behind Affinity Photo 2; Chat window; Friends list. (On the third crash all steam windows were closed, still running in the background) Minimised: Windows 11's Media Player, (Windows) Terminal, VS Code, Discord

Thank you all so much ❤️

Publisher crash. Because this is a problem across all apps I attach it here too instead of creating a new topic in the Publisher bug report forum. I'm sure, unlike previously suspected, AIMP does not cause these crashes. This crash happened without it running. The same applications as described in the previous post but AIMP ran this time. I hope these minidumps are useful, if not, let me know and I'll stop posting them. attachment_Log.txt e5033032-3ab3-47a7-9737-b61e4d248368.dmp

Another one with a crash log. Other programs opened while the crash happened: Foreground (opened on taskbar): Firefox, AIMP (minimised), Discord, MPC-HC, Notepad Background (minimised in system tray): Steam, Google Drive, KeePassXC, Powertoys I still have the suspicion that AIMP is causing some weird cross-compatibility issues, I'll switch the music player for a while and report back how this is going. 16a6dd29-67e1-48da-aeda-31e2340d0cc1.dmp attachment_Log.txt

AIMP utilises the GPU quite a bit when the Window is maximised, but almost none when minimised. I use it minimised most of the time. (That said, the Affinity also crash the GPU driver when I don't have AIMP open) @SrPx I don't think RAM is an issue here. Like said in my first post, I have 32 GB of RAM, that should be more than enough and the usage barely goes over 35% when working with the affinity apps with all the other background stuff I have open (Firefox, discord, etc.).

Hmmm, I always (barely don't) have firefox open with at least a twitch stream running, when I work mostly in the background (muted) to still support their channels, but then I'll listen to music in addition. I need these background noises to be able to concentrate.

Another crash - where the graphics driver was able to recover and therefore I have crash reports. @Callum I've reinstalled the GPU driver multiple times in the past, uninstalled via DDU to make sure everything is gone. Also my Windows is always up to date. I'm on the Beta update channel, I guess and hope this isn't a problem because I can't unenroll and change to a release build - without reinstalling Windows, I have to wait until the next one releases. I use the AIMP music player and I have the feeling that crashes are more likely to happen when I use this program to listen to music while working with the affinity apps - totally far-fetched and probably does have nothing to do with anything. Might be totally unrelated but I thought I might mention this. 295ba229-b989-4f0f-9329-d675b2a60030.dmp attachment_Log.txt

The Affinity apps crash my AMD display driver a lot and very random. Most of the times they happen when I move/pan or zoom the view. The screen where the App is running then will turn black, the system is still a little bit responsible (for example: media buttons still work) but not the display, the secondary display is frozen and it takes around half a minute for AMD to restore the graphics driver (I use the appearing crash report every time), in 99% of the cases the Affinity App has crashed too then. Sometimes (rarely) the graphic driver isn't able to restore itself, then I have to reset the PC, this will result in no crash reports on both sides. It is more likely to happen when I have Live Effect layers in the document. But sometimes the driver also crashes when I edit vector curves or for example change letter kerning/tracking on Artistic text. This problem is present in Affinity Photo, Affinity Designer, Affinity Publisher in Version 2 and 1. Enabling or disabling OpenCL hardware acceleration also has no effect on this issue. I have this issue for quite a while now and I've waited to report this issue for the OpenCL bug to be fixed, because I thought this might fix the issue. But no luck as it seems. Just for clarification before the blame is put on AMD again: Adobe Products, DaVinci Resolve, Krita, Blender, Inkscape do not have any issues on my hardware nor did the graphics driver ever crash once while I was using these Apps. In fact Affinity Apps (and Valheim in Vulkan) are the only source of display driver crashes on my PC. My PC configuration for reference: CPU: AMD Ryzen 7 3700X GPU: AMD Radeon RX 6800 XT (Driver: AMD Software: Adrenalin Edition Version 22.11.2) RAM: 32GB @ 3200MHz Display: 2x 1080p (144Hz + 72Hz) OS: Windows 11 Version 22H2 (OS Build 22623.1020) Crash Reports are attached 49f1e9ca-17cc-4679-931a-835f091b3c53.dmp attachment_Log.txt

Sounds amazing, thank you so much for listening to your community and customers!

From a bit of testing everything seems to work, apart from the presets and Studio Link (Publisher). I'm sure Studio Link can be fixed by hacking some Symlinks in place, not sure how to fix the presets tho. Going to set up a VM later to test this stuff.

I already think about doing serif's job and writing an application which extracts the MSIX archives, installs the files to the users destined location and registers the file associations automatically. I have to look if there's something like this out there already, so I don't have to "waste" my time on that matter. (didn't find anything yet) PS: It's also not "really" portable that way, the program settings and license information are stored in %localappdata%\Affinity

I'm not sure why you defend this behaviour, these are lame excuses. Of course it is a bit more work but that this will benefit the customer. The applications are self containing (apart from the user settings which are generated by the application itself), there is no cumbersome work to do to package them. it is as simple as that. They already have the tools and infrastructure for creating their MSI/EXE-installers from Version 1. Modifying this toolchain to work with V2 isn't an undoable task. Considering how much more customer and user friendly this approach is make the little bit of extra work worth to do. I have a software development background myself and for my projects I take extra steps to make the user experience pleasant and convenient. I don't want to attack you but I'm not sure if you are trolling, have no clue or think too complicated. I honestly don't know what you are talking about. This was already part of Version 1. And from my experience fetching update information on the client side isn't complicated and serving the release info via an API (or even just a normal string) on the server is also not a big deal. The testing of these features maybe takes a few hours up to a day for one person. They make a product and they want people to buy it, there is no defending in anti costumer practices because it's a little more comfy for the developers.

This FAQ mostly is a sham, I can see some valid points, but there is no reason not to simply give the customers the option to download either MSI/EXE or MSIX. Just offer MSIX as the first option for the non-technical users but give everyone who wants it the option to use the non-windows-app-crap MSI/EXE format. Not really, it's just a different installer packaging format. You can even simply one-click convert MSI/EXE installers to MSIX, so in that regard they can just have to maintain one version really.