Hey guys, I'm new here, so sorry if this post would be better fit under a different forum. Just let me know and I can repost it elsewhere.

I've got a real doozy here, so get ready for a story. I'll tell you guys exactly as it happened so there's good documentation of this specific failure; anyone not interested in reading a book, the TL;DR will cover it in less detail.

TL;DR:  An improperly remanufactured HMI has managed to write its original vehicle's immobilizer identifier to 4 other modules on this 2014 Cadillac SRX Luxury 3.6L V6 FLX FLEX FI, and according to numerous sources it will only continue to spread. Once it reaches a module that is integral to the immobilizer system, the vehicle will become a no-start. I need to find a way to either manually put the correct identifiers back into these 4 modules or find a way to properly virginize them. I'm planning to buy the Xhorse Multi-Prog programmer to attempt this; if any of you have other tools you recommend over this one, please let me know. I'm completely new to this, so basically any tips you guys have are much appreciated. Has anyone here ever run into this issue before?

First off, I'm a professional mechanic. I specialize in electrical diagnostics and get a very high volume of vehicles, therefore I get the chance to see some real weird shit; this is no exception. It started as a simple parasitic draw on a 2014 Cadillac SRX Luxury 3.6L V6 FLX FLEX FI. I diagnosed it and found the Human Machine Interface Control Module was causing the parasitic draw. Once the part was delivered, I installed it, programmed it using SPS2 and an MDI2, ran it through the set up procedure using SPS2 and an MDI2, then scanned it for DTCs. I found DTC B3902:00 was set in the HMI, indicating the remanufactured unit I had installed was not fully virginized during remanufacturing. This DTC is for Incorrect Immobilizer Identifier Received. General Motors official work-flow for this fault is to reprogram the module, then run the vehicle through an immobilizer relearn; if the DTC still returns, then the module must be replaced. I followed these instructions, but found that the DTC was still active. After cycling the key a few times, I rescanned the vehicle and found that DTC B3902 had now been set in the Instrument Panel Cluster, Electronic Brake Control Module, and the HVAC module, as well as the HMI.

Once I saw this, I called AC Delco's Diagnostic Hotline. I found that this exact issue has been documented, and never has a happy ending. In very rare cases on Global-A vehicles, when a used module is installed into a new vehicle while still containing the previous vehicle's security identifiers, the replacement modules' incorrect security identifiers can be rewritten to other modules on the networks. ACDelco has only seen this happen a couple dozen times, but it is a confirmed issue. In every case, all of the vehicles modules eventually relearned the incorrect security identifier, and the only fix is to replace every affected module at once, I.E. every module connected to the gateway. Once the incorrect identifier spreads to any of the modules integral to the antitheft system, the vehicle will also no longer be able to start. I was told to immediately remove the HMI from the vehicle to prevent further modules from being affected, to install a brand new one, and then after programming the HMI, to perform another immobilizer relearn on the vehicle.

Thankfully, in my case it had only spread to 3 others so far. I ordered a properly remanufactured HMI through GM and followed their instructions, but found the B3902 was still set in the IPC, EBCM, and HVAC. The only solution I was given by AC Delco was to replace all 3 modules with new ones. To make things worse, upon the next key cycle and scan, I found that the Inflatable Restraint Sensing and Diagnostic Module was now setting B3902 as well. The incorrect security identifier was still managing to continue spreading to other modules despite the HMI being replaced; absolute worst case scenario. I reached out to a couple of my contacts that deal with programming issues, and they also said they have seen this happen to Global-A vehicles. Much like AC Delco's reports, every time they had seen this issue, all modules in-network with the Gateway had already been affected. One of my contacts said that he had fixed these issues in the past by removing the MCUs from each module's PCB, virginizing them, reinstalling them, then reprogramming all modules on the vehicle. Sadly he said that these jobs were all far too time consuming and not something he would be interested in ever touching again, so im still on my own. 

I know all of this sounds crazy if you've never heard of it happening before, but I've had numerous sources confirm it as a known, extremely rare failure. Every single one agreed that it shouldn't be possible, but it is. My next step from what I can tell needs to be purchasing a programmer that will let me manually edit the bin file. From there I seem to have 3 options that I can think of.

1. Figure out what hexadecimal bytes contain the immobilizer/environment identifier, determine the vehicle's correct identifier from an unaffected module, and write the correct data into the affected modules. 

2.  Find a way to properly virginize the modules, likely requiring me to purchase the virgin files and write them to the affected modules.

3.  The obvious one that I'm trying to avoid, replace all affected modules.

If anyone here can come up with better options, I'm open to them. I'm planning to buy the Xhorse Multi-Prog Programmer here shortly so I can get started with this soon; if anyone here has a better tool they recommend over this, please let me know. Once I get the bin files I'll be sure to post them here. Has anyone here personally dealt with Global A B3902 propagation like this, or successfully corrected/virginized affected IPC, EBCM, HVAC, or SDM modules?

Hello,

I have this same code logged in the IPC of a Brazilian 2015 GM Onix 1.0 MT LT (Global A). Additionally, it appears as B3926-00 in the BCM.

Hi, "incorrect immobiliser identifier" you will get this DTC whenever you install a used module that's on the GM vehicle's secured system, for example, a used BCM, IPC, EBCM, etc. This happens because the used module's immobiliser security code differs from the vehicle you're repairing. To program the correct immobiliser identifier code for the vehicle you're repairing onto a used module, you need to use GM SPS or DPS to remove and reprogram the vehicle keys. Also, to remove and program the vehicle keys, all modules on the GM vehicle's secured system must have the same PIN and VIN stored in them.

More information is listed in this article.

The HMI is not part of the immobilizer, so it is extremely unusual for that DTC to be triggered by an HMI replacement.

The environment identifier is used to prevent the swapping modules between vehicles. The body control module (BCM) is the keeper of the environment identifier. The instrument cluster, electronic brake control module, HVAC control module, inflatable restraint sensing and diagnostic module, engine control module (ECM), and steering column lock module (if equipped) each learn the environment identifier during their configuration process. During vehicle operation, the BCM sends the immobilizer identifier as a challenge and each module responds to the challenge by sending the environment identifier back to the BCM. If the BCM sends an incorrect immobilizer identifier or a specific number of incorrect environment identifiers are received, vehicle starting is disabled.

I can confirm that it is usually a minimum of 2 incorrect envrionment identifiers that can trigger a vehicle starting to be disabled next time.

This is interesting as HMI is not part of Immobiliser enviroment. As @Arbe_gtc said. Any J2534 interface will do and we can help you with resetting them to factory :)

12 minutes ago, Adelin said:

This is interesting as HMI is not part of Immobiliser enviroment. As @Arbe_gtc said. Any J2534 interface will do and we can help you with resetting them to factory :)

I found it suprising too, but apparently every global-A module learns the identifiers, even the ones that arent integral to the imobilizer environment or use PINs.

Can you elaborate on what you mean by "any J2434 intrlerface will do?" I know what a J2534 is, i have all the major OEM ones including the MDI2. Are you saying that i can use it to reset the modules and/or edit bin files? With what software? From what ive seen, the basic vin reset, Pin reset, etc from DPS isnt guarenteed to fix it even after i spent all the money. In a normal situation, B3902 would be corrected by performing a simple Immobilizer relearn procedure, but ive done that twice with no luck. If the PIN or VIN were incorrect, then i should be setting other DTCs.

It seems like there are immobilizer identifiers stored somewhere in the bin file that SPS2 is unable to locate. It performs the procedure successfully, but fails to correct the B3902. I expect that the bytes will need to be manually located or the entire bin file will need to just be replaced with a virgin file.

Is it possible for you to run the VCAP on SPS2 and share the vcap file with us so we can review it?

14 minutes ago, Unhappy_Node said:

I found it suprising too, but apparently every global-A module learns the identifiers, even the ones that arent integral to the imobilizer environment or use PINs.

Can you elaborate on what you mean by "any J2434 intrlerface will do?" I know what a J2534 is, i have all the major OEM ones including the MDI2. Are you saying that i can use it to reset the modules and/or edit bin files? With what software? From what ive seen, the basic vin reset, Pin reset, etc from DPS isnt guarenteed to fix it even after i spent all the money. In a normal situation, B3902 would be corrected by performing a simple Immobilizer relearn procedure, but ive done that twice with no luck. If the PIN or VIN were incorrect, then i should be setting other DTCs.

It seems like there are immobilizer identifiers stored somewhere in the bin file that SPS2 is unable to locate. It performs the procedure successfully, but fails to correct the B3902. I expect that the bytes will need to be manually located or the entire bin file will need to just be replaced with a virgin file.

Software for this kind of stuff exists ;)

Are you sure that HMI made other modules reset their Security code? Or you tried to do something on the car that erased the security code from the modules you said. (key relearn)

For example if IPC does not have the correct Security code, it will throw an error for wrong environment. BCM will throw an error too because it doesn't recognize IPC as a module from the environment.

An incorrect security code simply prevents you from reprogramming the immobilizer (including relearning the environment ID). If everything in your vehicle is paired correctly and you change the IPC PIN, it won't trigger an "incorrect environment identifier" error.

The error appears when a used and unreset unit is installed in another vehicle; even if you correct the PIN and VIN, the error persists. I drove my car for a long time with a LaCrosse speedometer and error B3926 00 (Incorrect Environmental Identifier Received From Instrument Cluster) in the BCM, and nothing ever happened—until I relearned the keys.

2 minutes ago, Arbe_gtc said:

An incorrect security code simply prevents you from reprogramming the immobilizer (including relearning the environment ID). If everything in your vehicle is paired correctly and you change the IPC PIN, it won't trigger an "incorrect environment identifier" error.

The error appears when a used and unreset unit is installed in another vehicle; even if you correct the PIN and VIN, the error persists. I drove my car for a long time with a LaCrosse speedometer and error B3926 00 (Incorrect Environmental Identifier Received From Instrument Cluster) in the BCM, and nothing ever happened—until I relearned the keys.

Had same issue with retrofitted IPC. When i changed PIN to match BCM, error disappeared. No need for Key relearn.

In all the BCMs I’ve tested, the immobilizer environment DTC never cleared—even after simply changing the PIN and VIN—until I relearned the keys and the environment ID. There is a specific DID (though I don't recall which one) that "hides" the environment immobilizer DTC.

13 minutes ago, Adelin said:

Software for this kind of stuff exists ;)

Are you sure that HMI made other modules reset their Security code? Or you tried to do something on the car that erased the security code from the modules you said. (key relearn)

For example if IPC does not have the correct Security code, it will throw an error for wrong environment. BCM will throw an error too because it doesn't recognize IPC as a module from the environment.

After i installed the improperly remanufactured HMI, i did not perform an immobilizer relearn. All i performed was the applicable HMI configuration. After the installation and programming was complete, i scanned the vehicle and found B3902 was set in the IPC, EBCM, CCM, and the HMI, then spread further into the IRSDM after taking it for a test drive. These are all active DTCs and cannot be cleared.

As i said, this isnt supposed to be possible, but i have confirmed with multiple independant sources that this is a known, extremley rare issue. The issue was described the same way by everyone, including AC Delco themselves; the incorrect imobilizer identifier from the used module somehow propagates into the vehicles other modules, overwriting the other modules imobilizer identifiers. This is only known to happen on Global-A vehicles, usually the very early year models.

Nothing i did on sps2 after installing the used HMI should have had any effect on the immobilizer identifiers. Then after peforming no other procedures, the B3902 continued spreading, so far into just the IRSDM. This is exactly as other reports of this propagation issue have reported. I feel rather confident that this vehicle is experiencing the propagation glitch, not simply has configuration errors caused by failed service routines.

47 minutes ago, Opelinsignia1985 said:

Is it possible for you to run the VCAP on SPS2 and share the vcap file with us so we can review it?

Honestly, no idea. Ive never heard of vcap, and when i click on the name it brings me to a 404.

22 minutes ago, Adelin said:

Had same issue with retrofitted IPC. When i changed PIN to match BCM, error disappeared. No need for Key relearn.

Are you sure it was just the B3902 that was being reported? From what ive read, the PIN being incorrect should cause other DTCs other than B3902, which i do not have. If your right and a pin relearn can actually correct B3902, this may be something i need to look into.

39 minutes ago, Unhappy_Node said:

Are you sure it was just the B3902 that was being reported? From what ive read, the PIN being incorrect should cause other DTCs other than B3902, which i do not have. If your right and a pin relearn can actually correct B3902, this may be something i need to look into.

Pretty sure.

B3926 and B3980 are from BCM

B3902 is from IPC

53 minutes ago, Unhappy_Node said:

Honestly, no idea. Ive never heard of vcap, and when i click on the name it brings me to a 404.

That article about the Vcap tool was hidden. I unhide it. The link to the vcap word now works.

2 hours ago, Unhappy_Node said:

After i installed the improperly remanufactured HMI, i did not perform an immobilizer relearn. All i performed was the applicable HMI configuration. After the installation and programming was complete, i scanned the vehicle and found B3902 was set in the IPC, EBCM, CCM, and the HMI, then spread further into the IRSDM after taking it for a test drive. These are all active DTCs and cannot be cleared.

As i said, this isnt supposed to be possible, but i have confirmed with multiple independant sources that this is a known, extremley rare issue. The issue was described the same way by everyone, including AC Delco themselves; the incorrect imobilizer identifier from the used module somehow propagates into the vehicles other modules, overwriting the other modules imobilizer identifiers. This is only known to happen on Global-A vehicles, usually the very early year models.

Nothing i did on sps2 after installing the used HMI should have had any effect on the immobilizer identifiers. Then after peforming no other procedures, the B3902 continued spreading, so far into just the IRSDM. This is exactly as other reports of this propagation issue have reported. I feel rather confident that this vehicle is experiencing the propagation glitch, not simply has configuration errors caused by failed service routines.

You know if there are some TSB about that?