MSIX Runtime: Procmon and 0x368 result codes

%3CLINGO-SUB%20id%3D%22lingo-sub-228068%22%20slang%3D%22en-US%22%3EMSIX%20Runtime%3A%20Procmon%20and%200x368%20result%20codes%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-228068%22%20slang%3D%22en-US%22%3E%3CP%3EWhile%20troubleshooting%20a%20MSIX%20package%2C%20I%20ran%20a%20procmon%20trace.%26nbsp%3B%20I%20noticed%20several%20registry%20calls%20with%20an%20operation%20RegOpenKey%20that%20returned%20with%20a%20result%20code%20of%200x368.%26nbsp%3B%20The%20error%20code%200x368%20does%20not%20appear%20in%20the%20externally%20published%20windows%20error%20codes.%20And%20I%20don't%20ever%20recall%20seeing%20a%20numeric%20in%20the%20result%20column%20of%20a%20Procmon%20trace%20before!%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIt%20appears%20to%20me%20that%20this%20is%20a%20failure%20result%2C%20caused%20by%20the%20request%20being%20in%20incorrect%20case%20format%20for%20a%20portion%20of%20the%20key.%26nbsp%3B%20Specifically%2C%20I%20see%20it%20on%20requests%20for%20%22HKLM%5CSoftware%5C%E2%80%A6%22.%20%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20the%20cases%20that%20I%20have%20seen%20so%20far%2C%20the%20return%20is%20appropriately%20handled%20by%20the%20caller%20(or%20more%20likely%20by%20an%20API%20in%20between)%20and%20a%20secondary%20request%20is%20seen%20with%20the%20correct%20case%20(HKLM%5CSOFTWARE%5C%E2%80%A6.).%26nbsp%3B%20So%20in%20the%20examples%20that%20I%20have%20seen%20it%20isn't%20a%20real%20issue%2C%20just%20one%20that%20appears%20quite%20differently.%26nbsp%3B%20But%20there%20is%20always%20a%20chance%20that%20I%20haven't%20seen%20all%20the%20possible%20cases%20yet!%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIt%20would%20be%20nice%20if%20procmon%20were%20to%20be%20updated%20to%20resolve%20this%20error%20in%20a%20friendly%20name.%26nbsp%3B%20Perhaps%20the%20MSIX%20team%20can%20pass%20this%20on%20to%20whoever%20handles%20procmon%20these%20days%20(and%20maybe%20update%20that%20public%20error%20code%20list).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
MVP

While troubleshooting a MSIX package, I ran a procmon trace.  I noticed several registry calls with an operation RegOpenKey that returned with a result code of 0x368.  The error code 0x368 does not appear in the externally published windows error codes. And I don't ever recall seeing a numeric in the result column of a Procmon trace before!

 

It appears to me that this is a failure result, caused by the request being in incorrect case format for a portion of the key.  Specifically, I see it on requests for "HKLM\Software\…".  

 

In the cases that I have seen so far, the return is appropriately handled by the caller (or more likely by an API in between) and a secondary request is seen with the correct case (HKLM\SOFTWARE\….).  So in the examples that I have seen it isn't a real issue, just one that appears quite differently.  But there is always a chance that I haven't seen all the possible cases yet!

 

It would be nice if procmon were to be updated to resolve this error in a friendly name.  Perhaps the MSIX team can pass this on to whoever handles procmon these days (and maybe update that public error code list).

 

0 Replies