Rufus: Crash in WinToGo index selection on unofficial ISOs where the WIM doesn't have a DISPLAYNAME entry

[MagicAndre1981]

Checklist

• [x] I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• [x] I performed a search in the issue tracker for similar issues, using keywords relevant to my problem.
• [ ] I clicked the Log button in Rufus and copy/pasted the log into the line that says <FULL LOG> below. (can't do this as rufus crashes without giving me a log)
• [ ] The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Issue description

When I select "WinToGo" as destination in rufus 2.15, 2.16, rufus crashes when I click to start the action. Because it crashes, I get no log, but I compiled rufus on my own and activated the option to generate PDBs to help debugging, so I post the Windbg result:

Log

0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

DUMP_CLASS: 2

DUMP_QUALIFIER: 400

CONTEXT:  (.ecxr)
rax=900004045b015b60 rbx=000000b0cb58dee0 rcx=900004045b015b59
rdx=000000007fffffff rsi=000000007fffffff rdi=900004045b015b59
rip=000007f7a625147f rsp=000000b0cb58ddc8 rbp=000007f7a626b050
 r8=0000000000000000  r9=900004045b015b59 r10=0000000000000007
r11=000000b0cb58dea0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000001
iopl=0         nv up ei ng nz na po cy
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010287
rufus!common_strnlen_c+0x19 [inlined in rufus!strnlen+0xcf]:
000007f7`a625147f 803900          cmp     byte ptr [rcx],0 ds:90000404`5b015b59=??
Resetting default scope

FAULTING_IP: 
rufus!strnlen+cf [minkernel\crts\ucrt\src\appcrt\string\strnlen.cpp @ 201]
000007f7`a625147f 803900          cmp     byte ptr [rcx],0

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 000007f7a625147f (rufus!common_strnlen_c+0x0000000000000019)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: ffffffffffffffff
Attempt to read from address ffffffffffffffff

DEFAULT_BUCKET_ID:  INVALID_POINTER_READ

PROCESS_NAME:  rufus.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

EXCEPTION_CODE_STR:  c0000005

EXCEPTION_PARAMETER1:  0000000000000000

EXCEPTION_PARAMETER2:  ffffffffffffffff

FOLLOWUP_IP: 
rufus!strnlen+cf [minkernel\crts\ucrt\src\appcrt\string\strnlen.cpp @ 201]
000007f7`a625147f 803900          cmp     byte ptr [rcx],0

READ_ADDRESS:  ffffffffffffffff 

WATSON_BKT_PROCSTAMP:  59804e9d

WATSON_BKT_PROCVER:  2.16.1171.0

PROCESS_VER_PRODUCT:  Rufus

WATSON_BKT_MODULE:  rufus.exe

WATSON_BKT_MODSTAMP:  59804e9d

WATSON_BKT_MODOFFSET:  b147f

WATSON_BKT_MODVER:  2.16.1171.0

MODULE_VER_PRODUCT:  Rufus

THREAD_ATTRIBUTES: 
OS_LOCALE:  DEU

PROBLEM_CLASSES: 

    ID:     [0n301]
    Type:   [@ACCESS_VIOLATION]
    Class:  Addendum
    Scope:  BUCKET_ID
    Name:   Omit
    Data:   Omit
    PID:    [Unspecified]
    TID:    [0x1ee4]
    Frame:  [0] : rufus!strnlen

    ID:     [0n273]
    Type:   [INVALID_POINTER_READ]
    Class:  Primary
    Scope:  DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
            BUCKET_ID
    Name:   Add
    Data:   Omit
    PID:    [Unspecified]
    TID:    [0x1ee4]
    Frame:  [0] : rufus!strnlen

BUGCHECK_STR:  APPLICATION_FAULT_INVALID_POINTER_READ

PRIMARY_PROBLEM_CLASS:  APPLICATION_FAULT

LAST_CONTROL_TRANSFER:  from 000007f7a62207ff to 000007f7a625147f

STACK_TEXT:  
00 ntdll!NtWaitForMultipleObjects
01 KERNELBASE!GetProcessHeap
02 kernel32!WerpReportFaultInternal
03 kernel32!WerpReportFault
04 KERNELBASE!UnhandledExceptionFilter
05 ntdll!LdrpLogFatalUserCallbackException
06 ntdll!KiUserCallbackDispatcherHandler
07 ntdll!RtlpExecuteHandlerForException
08 ntdll!RtlDispatchException
09 ntdll!KiUserExceptionDispatch
0a rufus!common_strnlen_c
0b rufus!common_strnlen_simd
0c rufus!common_strnlen
0d rufus!strnlen
0e rufus!__crt_stdio_output::output_processor<char,__crt_stdio_output::string_output_adapter<char>,__crt_stdio_output::format_validation_base<char,__crt_stdio_output::string_output_adapter<char> > >::type_case_s_compute_narrow_string_length
0f rufus!__crt_stdio_output::output_processor<char,__crt_stdio_output::string_output_adapter<char>,__crt_stdio_output::format_validation_base<char,__crt_stdio_output::string_output_adapter<char> > >::type_case_s
10 rufus!__crt_stdio_output::output_processor<char,__crt_stdio_output::string_output_adapter<char>,__crt_stdio_output::format_validation_base<char,__crt_stdio_output::string_output_adapter<char> > >::state_case_type
11 rufus!__crt_stdio_output::output_processor<char,__crt_stdio_output::string_output_adapter<char>,__crt_stdio_output::format_validation_base<char,__crt_stdio_output::string_output_adapter<char> > >::process
12 rufus!common_vsprintf<__crt_stdio_output::format_validation_base,char>
13 rufus!common_vsnprintf_s
14 rufus!__stdio_common_vsnprintf_s
15 rufus!_vsnprintf_s_l
16 rufus!_vsnprintf_s
17 rufus!_uprintf
18 rufus!SetWinToGoIndex
19 rufus!BootCheck
1a rufus!MainCallback
1b user32!UserCallDlgProcCheckWow

SYMBOL_NAME:  rufus!strnlen+cf

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: rufus

IMAGE_NAME:  rufus.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  59804e9d

STACK_COMMAND:  ~0s ; .ecxr ; kb

FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_rufus.exe!strnlen

BUCKET_ID:  APPLICATION_FAULT_INVALID_POINTER_READ_rufus!strnlen+cf

FAILURE_EXCEPTION_CODE:  c0000005

FAILURE_IMAGE_NAME:  rufus.exe

BUCKET_ID_IMAGE_STR:  rufus.exe

FAILURE_MODULE_NAME:  rufus

BUCKET_ID_MODULE_STR:  rufus

FAILURE_FUNCTION_NAME:  strnlen

BUCKET_ID_FUNCTION_STR:  strnlen

[pbatard]

Please provide the full log from Rufus after selecting your ISO and before clicking Start. There's a lot of information that I can get, even without the one that leads to the issue, that is critical to investigating the problem.

[MagicAndre1981]

The issue is unrelated to anything in the log (you can only see that I want to use RS3 Build 16251). Your logging has issues:

rufus!_uprintf(char * format = 0x000007f7`a627aab0 "Will use '%s' (Build: %d, Index %s) for Windows To Go")+0x5c [d:\rufus\src\stdio.c @ 54] 
rufus!SetWinToGoIndex(void)+0x3d8 [d:\rufus\src\format.c @ 1345] 

this leads to the crash

Rufus version: 2.16.1171 (Portable)
Windows version: Windows 8 64-bit (Build 9200)
Syslinux versions: 4.07/2013-07-25, 6.03/2014-10-06
Grub versions: 0.4.6a, 2.02
System locale ID: 0x0407
Will use default UI locale 0x0407
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'de-DE'
Found UAS (USB 3.0) device 'asmedia ASMT1153E SCSI Disk Device' (174C:55AA)
Device eliminated because it was detected as a Hard Drive (score 6 > 0)
If this device is not a Hard Drive, please e-mail the author of this application
NOTE: You can enable the listing of Hard Drives in 'Advanced Options' (after clicking the white triangle)
0 devices found
Found UAS (USB 3.0) device 'asmedia ASMT1153E SCSI Disk Device' (174C:55AA)
1 device found
Disk type: FIXED, Sector Size: 512 bytes
Cylinders: 30401, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: GPT, NB Partitions: 3
Disk GUID: {8134C05A-D7EE-4C6D-BD02-89E3B1A5264F}
Max parts: 128, Start Offset: 17408, Usable = 250059315712 bytes
Partition 1:
  Type: {E3C9E316-0B5C-4DB8-817D-F92DF00215AE}
  Name: 'Microsoft reserved partition'
  ID: {A46547B1-8BC9-459B-9BD4-5792C3EED8ED}
  Size: 128 MB (134217728 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000000
Partition 2:
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'Microsoft Basic Data'
  ID: {E6CEE2A0-1D50-4826-A7BA-9722AE206185}
  Size: 232.7 GB (249819171840 bytes)
  Start Sector: 264192, Attributes: 0x0000000000000000
Partition 3:
  Type: {C12A7328-F81F-11D2-BA4B-00A0C93EC93B}
  Name: 'EFI system partition'
  ID: {E8515BF1-FC3A-4637-883E-E08E5FFC222B}
  Size: 100 MB (104864256 bytes)
  Start Sector: 488192262, Attributes: 0x0000000000000000
Scanning image...
ISO analysis:
  Image is an UDF image
Disk image analysis:
  Image does not have an x86 Master Boot Record
ISO label: 'J_CPRA_X64FRE_DE-DE_DV5'
  Size: 4.0 GB (Projected)
  Uses: EFI
  Uses: Bootmgr
  Uses: Install.wim (version 0.13.1)
Using image: 16251.0.170721-2122.RS3_RELEASE_CLIENTPRO_OEMRET_X64FRE_DE-DE.ISO

[pbatard]

The issue is unrelated to anything in the log

It is, because it is related to the ISO and possibly the platform you are using as well as other potential factors (possibly the locale), that are being logged for the __specific reason__ of helping me troubleshoot these kind of issues. For you reference, this issue is not something that I have been able to replicate or that any other user of Rufus has ever reported with the official ISOs from Microsoft, which is why, at the very least, I need to have more data about the ISO you are using, data that I know I can always get from the log.

There's a reason why I ask anyone who creates an issue to always provide a log. Even with your partial stack trace, without information about the ISO you are using, or your platform or your locale, I could spend __DAYS__ trying to replicate an issue that would otherwise take me 1 min, by simply using the data I get from the log to test in the same conditions as the ones where the problem was observed. Trying to fix issues in the blind (i.e. without being able to replicate the original problem) is the shortest way to:

1. Not fixing the issue at all
2. Introducing more issues

Now, from what I could see, 16251.0.170721-2122.RS3_RELEASE_CLIENTPRO_OEMRET_X64FRE_DE-DE.ISO doesn't seem to be an official ISO from Microsoft (or at least, the only links I found are most certainly on non-official servers such as Mega). So the first thing I'd like to ask is: Is this an official Microsoft ISO? And if not, have you been able to see the same issue with official ISOs?

[pbatard]

Oh, and for your reference, if you equate a NULL or invalid pointer derefence, invoked during logging, to _"Your logging has issues"_, and believe that locating the cause of the invalid derefence is superfluous to fixing the issue (i.e. the __precise__ reason why the trace you provided was not enough and I asked for more data), I suggest you take a few online courses about software development. Please don't make the beginner's mistake of assuming that, because you provided a trace, everything that's required to identifying the cause of an issue and its fix has been made available.

[MagicAndre1981]

You access version_name and version_index which are both NULL.

This happens here because the WIM has only 1 index, because this is a selfmade ISO (decrypt-multi-release) from UUP data during upgrading from 16241 to 16251.

So you do the noob mistake nr. 1 to access variables without NULL checks and try to tell others what they do wrong. I'm out of this discussion. You are god and I have peace and quiet.

[MagicAndre1981]

and as expected, commenting out the buggy log call fixes it. Now I can create a WinToGo drive successfully.

[pbatard]

This happens here because the WIM has only 1 index

That's where your analysis is wrong.

Please feel free to test with the official en_windows_8.1_enterprise_with_update_x64_dvd_4065178.iso, which has an install.wim with only one index, and see if it crashes.

So you can get down of your high horse now, and let actual developers do their job of __properly__ analysing issues.

because this is a selfmade ISO

And of course you expect applications to perform tests against self made ISOs?

Unfortunately for your nice attempt of deflecting what I called you out on, which was that you __only__ provided a trace, and no information whatsoever about the ISO you are using, because you wanted to pretend that the log was superfluous, you have just disproved your own point. That is unless you expect developers to have magic balls and __guess__ the specifics of one's custom ISOs.

Again, even it may come as a suprise to you since I'm supposed to be a noob developer, but I did test many official ISOs since I introduced the index selection (including ones that only have one index) and none had this issue.

With 2.15 you added the option to choose between indexes and this is why it doesn't crash in 2.14.

Yes. And water is wet. But being aware that this has something to do with index selection, or even the number of indexes, is not all there is to the issue, as we have just established.

So you do the noob mistake nr. 1 to access variables without NULL checks

If we go by your standards, then every developer is a noob, coz this is certainly not the first NULL dereference you'll find in Rufus or other software, nor will it be the last. There's a reason why this is the most common issue in C applications, and there's hardly an experienced developer out there that will pretend they are immune to overlooking a NULL deref.

Of course, and this is the kicker here, the actual __noob mistake__ is to think that adding a NULL check is the solution, whereas the actual resolution is to identify the reason why the NULL pointer exists in the first place and prevent that. But hey, feel free to believe that commenting code, without understanding why it fails on one ISO and not another, somehow makes you a leet coder...

Then again, and even more damning, if you want to lecture someone on NULL checks and noob mistakes, __you better make sure that there is an actual NULL check issue... which there isn't__

As a matter of fact, you can pass NULL for __ALL of the parameters for the log call you pointed out__, and you will see no crash at all. In other words, this log call:

uprintf("Will use '%s' (Build: %d, Index %s) for Windows To Go", NULL, NULL, NULL);

Will result in Rufus happily printing this:

Will use '(null)' (Build: 0, Index (null)) for Windows To Go

Instead, the __actual__ issue is an out of bound index, and there's no _"noob mistake nr. 1 to access variables without NULL checks"_ here. But please don't let reality distract you from a good mic drop...

and as expected, commenting out the buggy log call fixes it. Now I can create a WinToGo drive successfully.

There are so many wrong assertions in this statement, I don't even know where to begin.

1. Despite the narrative you'd like to see, so that it fits your erroneous claim, the log call isn't buggy (as a matter of fact, it will happily print NULL string pointers), but the issue is that the index is 0.
2. You "fix" is not a fix at all, as we'll establish below, since it won't allow you to select an index for multiindex WIMs.
3. "Successfully" is very relative if you can't choose the index you want, and actually have no idea what the application will pick for you.

[pbatard]

Now, if you want to be __useful__, and since I know that you are used to helping people (which I am usually thankful for, even though I suspect this may influence you to look down on any deserved criticism), do you know if there a specification for the index data that is supposed to the present in a WIM?

The __actual__ issue here is that I have been assuming that an official WIMs should always have a <DISPLAYNAME> element (since, logically, what I want to prompt a user with in Rufus, if there is a choice, is the name that Microsoft sees as the name to __display__), but your ISO doesn't have that element (just <DESCRIPTION>), hence the reason why the list of index Rufus collects on your ISO is empty.

I guess the one fix I can go with is to use <DESCRIPTION> instead of <DISPLAYNAME>, since, from the official ISOs I am looking at, they tend to be the same. But then again, if there's something that states that official Microsoft ISOs should always have a <DISPLAYNAME>, I may do something different.

[pbatard]

Just for reference, this is the WIM XML index of the problematic ISO:

<WIM>
  <IMAGE INDEX="1">
    <DIRCOUNT>20794</DIRCOUNT>
    <FILECOUNT>101717</FILECOUNT>
    <TOTALBYTES>16239795365</TOTALBYTES>
    <HARDLINKBYTES>7455936487</HARDLINKBYTES>
    <CREATIONTIME>
      <HIGHPART>0x01D30389</HIGHPART>
      <LOWPART>0x56754FBB</LOWPART>
    </CREATIONTIME>
    <LASTMODIFICATIONTIME>
      <HIGHPART>0x01D3064C</HIGHPART>
      <LOWPART>0x55B0989E</LOWPART>
    </LASTMODIFICATIONTIME>
    <WIMBOOT>0</WIMBOOT>
    <WINDOWS>
      <ARCH>9</ARCH>
      <PRODUCTNAME>Microsoft® Windows® Operating System</PRODUCTNAME>
      <EDITIONID>Professional</EDITIONID>
      <INSTALLATIONTYPE>Client</INSTALLATIONTYPE>
      <SERVICINGDATA>
        <GDRDUREVISION>0</GDRDUREVISION>
        <PKEYCONFIGVERSION>10.0.16251.0;2016-01-01T00:00:00Z</PKEYCONFIGVERSION>
      </SERVICINGDATA>
      <PRODUCTTYPE>WinNT</PRODUCTTYPE>
      <PRODUCTSUITE>Terminal Server</PRODUCTSUITE>
      <LANGUAGES>
        <LANGUAGE>de-DE</LANGUAGE>
        <FALLBACK LANGUAGE="de-DE">en-US</FALLBACK>
        <DEFAULT>de-DE</DEFAULT>
      </LANGUAGES>
      <VERSION>
        <MAJOR>10</MAJOR>
        <MINOR>0</MINOR>
        <BUILD>16251</BUILD>
        <SPBUILD>0</SPBUILD>
        <SPLEVEL>0</SPLEVEL>
      </VERSION>
      <SYSTEMROOT>WINDOWS</SYSTEMROOT>
    </WINDOWS>
    <NAME>Windows 10 Pro</NAME>
    <DESCRIPTION>Windows 10 Pro /EA</DESCRIPTION>
  </IMAGE>
  <TOTALBYTES>3591579954</TOTALBYTES>
</WIM>

And this is the WIM XML index of an official Microsoft ISO with a single entry (but with a <DISPLAYNAME>):

<WIM>
  <TOTALBYTES>3346147039</TOTALBYTES>
  <IMAGE INDEX="1">
    <DIRCOUNT>17622</DIRCOUNT>
    <FILECOUNT>89221</FILECOUNT>
    <TOTALBYTES>12607141550</TOTALBYTES>
    <HARDLINKBYTES>5254020897</HARDLINKBYTES>
    <CREATIONTIME>
      <HIGHPART>0x01CF4298</HIGHPART>
      <LOWPART>0x56746BFB</LOWPART>
    </CREATIONTIME>
    <LASTMODIFICATIONTIME>
      <HIGHPART>0x01CF4298</HIGHPART>
      <LOWPART>0xA4EDD9AC</LOWPART>
    </LASTMODIFICATIONTIME>
    <WIMBOOT>0</WIMBOOT>
    <WINDOWS>
      <ARCH>9</ARCH>
      <PRODUCTNAME>Microsoft® Windows® Operating System</PRODUCTNAME>
      <EDITIONID>Enterprise</EDITIONID>
      <INSTALLATIONTYPE>Client</INSTALLATIONTYPE>
      <SERVICINGDATA>
        <GDRDUREVISION>20140317</GDRDUREVISION>
        <PKEYCONFIGVERSION>6.3.9600.17031;2014-02-22T04:31:22Z</PKEYCONFIGVERSION>
      </SERVICINGDATA>
      <HAL>acpiapic</HAL>
      <PRODUCTTYPE>WinNT</PRODUCTTYPE>
      <PRODUCTSUITE>Terminal Server</PRODUCTSUITE>
      <LANGUAGES>
        <LANGUAGE>en-US</LANGUAGE>
        <DEFAULT>en-US</DEFAULT>
      </LANGUAGES>
      <VERSION>
        <MAJOR>6</MAJOR>
        <MINOR>3</MINOR>
        <BUILD>9600</BUILD>
        <SPBUILD>17031</SPBUILD>
        <SPLEVEL>0</SPLEVEL>
      </VERSION>
      <SYSTEMROOT>WINDOWS</SYSTEMROOT>
    </WINDOWS>
    <NAME>Windows 8.1 Enterprise</NAME>
    <DESCRIPTION>Windows 8.1 Enterprise</DESCRIPTION>
    <FLAGS>Enterprise</FLAGS>
    <DISPLAYNAME>Windows 8.1 Enterprise</DISPLAYNAME>
    <DISPLAYDESCRIPTION>Windows 8.1 Enterprise</DISPLAYDESCRIPTION>
  </IMAGE>
</WIM>

Oh, and I also checked the latest official Insider release (Windows10_InsiderPreview_Client_x64_en-us_16232.iso, which has 2 indexes, but which doesn't matter since Rufus will fail just the same on reconstructed WIM with multiple indexes but without <DISPLAYNAME>'s), and confirmed that it does have <DISPLAYNAME> elements. hence, my current expectation is that __only__ unofficial ISOs will display the behaviour described in this issue.

[pbatard]

Looking at this further, I don't think we want to switch to using <DESCRIPTION> instead of <DISPLAYNAME>, as you would then get the following choice selection for en_windows_7_ultimate_with_sp1_x64_dvd_618240.iso:

instead of the much more presentable:

There's a good reason why Microsoft uses a <DISPLAYNAME> in their ISOs...

I guess I have two choices here:

1. Say screw it to people who create their own unofficial ISOs, but don't respect the same conventions as Microsoft, and force them to use the first index always (i.e. no choice of version)
2. Add a fallback so that if <DISPLAYNAME> is not found <DESCRIPTION> is used. Of course, since I'm not planning to spend too much time on a fallback meant for people who don't use official ISOs, what I have in mind will probably fall apart if the ISOs has sections with both <DISPLAYNAME> __and__ <DESCRIPTION> and others with only <DESCRIPTION>, but that's what you get from thinking you can do a better job than Microsoft, and I'm certainly not gonna add a dependency on expat in Rufus just so that we can properly parse that XML.

[pbatard]

Well, since OP has chosen to take the high road, and hasn't had the decency to come back to acknowledge his many erroneous assertions, and before I close this issue, I will produce a post-mortem that I believe can serve as a very good example of what __not__ to do when logging an issue.

This way, I'll be able to use this entry as an educational warning of what to avoid, in order not to lose all credibility when asking a developer to look into your problem.

For the sake of brevity, I'll keep it to 4 major points:

1. Never try to judge what data is relevant or is not relevant to an issue and don't make the mistake of assuming because __you__ are experiencing a problem it can be easily replicated. In this case, OP decided that mentioning the very custom and non official ISO he was using was completely superfluous and that the log data was irrelevant. Furthermore, he appeared to assume that the issue he observed would probably affect all Windows To Go users using Rufus 2.15 or 2.16. Considering the number of people who use Rufus on a daily basis it's usually very unlikely that you have uncovered something major and chances are that there's an very environmental component that plays a big part in your issue. Therefore, you should __never__ consider that withholding data about your environment is acceptable or even innocuous.

2. Learn to keep your ego in check. It's not because you have a bit more knowledge than some others (_"I can produce a WinDbg trace!"_), that it makes you qualified to give advice on a subject that you clearly have little understanding of. As is the case here, the data provided by WinDbg was quite useless, as it didn't give any hints at identifying that the underlying issue came from trying to process an install.wim where <DISPLAYNAME> entries are missing. And __exactly__ as I tried to point out, without the additional data requested, I would both have wasted __days__ trying to replicate the issue and, most likely, would have tried to add a "fix" that would have introduced new issues, such as the inability to choose between a Windows versions on custom ISOs. So, yes, even if you are a well regarded member of your own little technical community, you might want to give some credit to the idea that, maybe, the person you come to with a request might have a better idea on how to properly satisfy that request than you do. As many philosophers have been keen to point out, a little bit of knowledge on a subject matter is often more dangerous than no knowledge at all, as it can lead to many wrong shortcuts and assertions and the damaging belief that one stands with equal footing as the experts from that field.

3. If you are going to point the finger or jump to specific conclusions, then you'd better try to validate these conclusions first, lest you want to look like a fool. In this case, OP made many wrong assumptions, that were easy to debunk, such as:

   • Wanting to pretend that _"the issue was unrelated to anything from the log"_ (it was)
   • _"(Rufus)' logging had issues"_ (it doesn't - As can easily be demonstrated, it happily takes NULL values without crashing, and this is not even a lucky accident)
   • _"(The crash) happens here because the WIM has only 1 index"_ (it doesn't, as we can demonstrate that there exists WIMs with one index where the crash will not occur, and WIMs with more than one where it will)

4. Likewise, if you are going to get on your high horse and try to lecture someone on _"noob mistakes"_, you might want to double check that you actually understand the _"noob mistake"_ you are describing and that it is both present and valid. Otherwise, all you are going to do is discredit yourself. In this case, we have OP trying to give a lecture on NULL checks, despite not understanding that there weren't any NULL pointers to check on, and that, even if there were, they wouldn't even have crashed section of code he pointed at. Ouch!

I'll just conclude that, despite what it seem some individuals are keen on believing, issue reports are not place where you get Internet street cred'. So you can leave attempts at a mic drop and exiting the scene with a overly raised chin to actual rap battles, and at least have the decency to acknowledge your mistakes when you are repeatedly proven wrong.

[MagicAndre1981]

I don't discuss with users who have no idea what they do. Take a course with the topic "defensive programming" and learn to make code reliable.

[pbatard]

I don't discuss with users who have no idea what they do

That assertion would work a lot better if you could show that this has ever been the case here, which you have repeatedly failed to demonstrate. Instead, all we've seen is that you have been jumping to erroneous conclusions over and over, about what information was needed, or where the problem was located, or even the type of issue that the _noob_ that I (allegedly) am should have proactively "defended" against. So, if I too were to pass arbitrary judgement, I would say that the facts, so far, have supported in a pretty eloquent manner that __you__ are instead the person with the most limited knowledge here.

And, while I can certainly understand why, coming from an environment where the situation is usually reversed and where you are dealing with people who are more clueless than you are, you may have some trouble adjusting, I also have to say that you are not doing yourself any favour by trying to double down on the "I'm more of an expert on software development than you will ever be", especially when your public history fails to provide any credibility to that supposition.

Take a course with the topic "defensive programming" and learn to make code reliable.

In that case, may I suggest that you enroll in a "Gracefully acknowledging when you are wrong and moving on" course?

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.