Error: cab file could not be created - No, not again! Nice workaround/solution
====>SiteMap of this Blog<===Error: cab file could not be created - No, not again! Ultimate workaround/solution
How many times did you see the dreaded message "Error: CAB file 'XXX.CAB' could not be created", after you managed to tackle the compilation error, managed to build the needed DLLs, EXEs, and managed to write a good CAB .inf file? Worse, the error file that CabWiz is supposed to dump error message is empty! This left you cluelessly scratching your head, having no idea what exactly you did wrong.
I have seen so many such errors in my development, and I do not think I did anything wrong. Why? Here is my story posted to Microsoft MSDN forum. Sometimes the new CabWiz (shipped with VS2005) worked, sometimes did not. Sometimes the old CabWiz (shipped with PPC2003 SDK) worked, sometime did not. Sometimes everything worked in my PC, but not in my teammate's...
With the incredible tool from the wizards in sysinternals, I monitored the file-system activities after launching CabWiz. Looks like CabWiz first analyzed the .INF file, generated an intermediate file based on a template (cabwiz.ddf), then asked makecab.exe to build the CAB based on the intermediate file. Makecab failed at the stage when a CAB was being created, for no apparent reason. That explained why CabWiz could not report any meaningful error message, because makecab.exe did not communicate with CabWiz why it failed.
Finally I figured out probably the buggy tool is not comfortable with the long fully-qualified CAB filename. So I did a subst, making sure the current directory for CabWiz is very short. Viola! It works. So the ultimate solution is to use Subst to shorten the absolute name of your CAB file, and launch CabWiz from that shorten path.
Example:
Original path of INF file
c:\MyWork\WindowsMobile\superlong1\superlogn2\superlong3 superlogn4\superlogn5\superlogn6\superlogn7 MailClient\src\Shared\MailClient_release.PPC2003_en.inf
Do a subst:
Subst v: c:\MyWork\WindowsMobile\superlong1\superlogn2\superlong3 superlogn4\superlogn5\superlogn6\superlogn7
Then file Cabsize in V: rather than in C:
Sometimes even if the original path is not very long (like 120 characters), CabWiz still fails. A subst is still a good solution.PS: Microsoft's documentation on Subst. Or you can type "subst /h" on the command line to see the details how it works.
Category: [Cabwiz / Build]
====>SiteMap of this Blog<===
posted by Lao K
Error: cab file could not be created - No, not again! Nice workaround/solution at 12:42 PM
10 Comments:
Thats a useful workaround.
My own workaround is not to create projects in folders that have spaces in their names. I've reported this as a bug to MS but they are having a problem solving it as they can't reproduce it!
Interesting that you have isolated the probelm down to makecab.exe rather than cabwiz. I'm just doing a search on my system to see how many diffrent versions of makecab.exe I have found 5....I'm going to test them all tomorrow.
Will Chapman
I remembered that once a guy from inside Microsoft acknowledged that there are so many version of makecab.exe and some of them are really buggy. I actually tried to replace the makecab.exe in the PPC SDK directory with the one under windows, but still, did not work.
Let me know if you have better results.
If it still doesnt solve the problem, check your registry for the following key NtfsDisable8dot3NameCreation under
HLM/SYSTEM/CurrentControlSet/Control/FileSystem
The type should be REG_DWORD
It should be set to 1.
Restart your machine and things will work just fine.
Vino.
Hello,
Thanks for the tip, it's really sympathic to find this kind of tip on your blog. Nevertheless I wish let you know something :
I build my cab on two different computers (both use Win XP Pro OS and VS 2005 version 8.0.57727.42 and the same mobile SDKs and APIs).
One managed to built the cab file and the value of its NtfsDisable8dot3NameCreation reg key was 0 !
But I had to build the cab project after the rest of the solution because rebuild all the solution with the cab project included totally crash VS 2005.
The other computer give me in output our problem : "error cab file could not be created". But on this one the value of the NtfsDisable8dot3NameCreation was 1 !
The both cab projects on the both computers are built on an NTFS file system. So what I did :
I tried to switch the value of NtfsDisable8dot3NameCreation on the both computers. The result : it didn't change anything for the one which couldn't create the cab. And the big surprise is : the one which managed to build the cab file don't manage to do it anymore even if I restore the NtfsDisable8dot3NameCreation to 0 !!! (i also didn't forget to reboot ^^)
Conclusion : my cab project is ... :-) hope I'll be able to fix this ...
I also tried the substr stuff but it don't seem to be the problem at all (I send a mail to Lao about this).
I'm so disappointed ... Do you think we'll have a stable release of makecab.exe for smart device someday guys ?
Thanks a lot for your attention and your advices
Bye
Seb
I've found the cabwiz/makecab duo to be much pickier when the files are on a network drive.
Basically, no spaces are allowed in the path of any source if its on a network drive. Also, if the source paths are on a network drive, then the output path better be as well, else it fails to open the files (some memory mapped I/O mucking from what I gather). (Note, signtool.exe also fails on a network drive, but if you call it twice in a row, it succeeds and the output binary is identical to copying to a local drive and signing, it just does the PE header fixup to add the signature region on the first pass and then actually attaches the signature in the second pass. the error from the first pass is something like "no valid PE header", even though it just found and patched it.)
Next up, no relative paths (almost). If you are D:\project, then D:\SDK\bin or \SDK\bin would be ok, but ..\SDK\bin would not be. This makes working around the prior more fun.
There's no way to feed any information, such as environment variables, info a .inf used for guiding CAB building. No pulling stuff from $TEMP$ for example, which could otherwise be used to relieve some other restrictions.
A whole mess of characters are no longer supported in a .inf file with the current vs2005/wm5 cabwiz. The old evc4/ppc2003 cabwiz allowed a lot more characters, which found their way into a variety of registry entries that become user visable and need certain character for internationalization or just to fit the entries being added to.
Once you get through the pain of creating the cab, then there's the fun of installing it. The cab installer uses non-reentrant code, so you can't chain installers and you can't call DMProcessConfigXML from your setup.dll since the cab installer is in that code.
Those are just the limits on a good day. I've found that sometimes it'll claim a cab is invalid or the install was unsuccessful (immediately upon clicking the cab), and if I just keep clicking the cab it'll remember how to parse files again and install it just fine. Sometimes a cab will bail out during an upgrade due to a failure to overwrite a non-locked file. The count of failed files and folders will always be wrong. Deleting all the files in Install_Init that might get overwritten will prevent this.
Finally, uninstalling seems to bnever clean up the files and registry keys. It'll get a few, but leave others that weren't modified in any way since install. So, have to have an uninstall routine that goes and deletes everything after the system uninstall. This is habdy to have around for calling before upgrade too (see above).
In the name of accuracy, I have to rebuff some comments made in the last comment. I have nothing to back up my statements except for my own experience...
"...no spaces are allowed in the path of any source if its on a network drive..."
I have two source paths in my INF file, both of which have spaces. They, however, do have to be wrapped in double-quotes.
"...if the source paths are on a network drive, then the output path better be as well..."
The aforementioned source paths are on a network volume, but the resulting CAB file resides locally.
Again, I wish no disrespect to the poster, but I do want this additional information available for others who come after me.
After Searching the web, etc.
Tried Subst could not get it to work for me.
Using VS2008 Mobile Device Cabwiz
I too had to still use a new folder with no spaces before it would compile into a cab. Like always microsoft can't get it right!
Excellent article! I can confirm this bug still exists in VS2008 SP1. May indeed be that the path to the output folder for the CAB-file is not allowed to have spaces in it.
We've been having similar problems. One day it stopped working for no apparent reason. File System Monitor saved the day here too. Turns out CabWiz version > 4.x is creating a temp file at \documents and settings\%user%\local settings\temp\wiz* each time it runs and not cleaning up that temp file. We deleted those files and it works again. We have seen this with CabWiz v4.04 and v4.5.
Just as a follow up. I also had this issue and it turned out to be the path used for my temporary directory which was pointing to c:\documents and settings....... I change my environment variable TMP to point at c:\temp and all worked just fine. BTW, this error was happening in the makecab.exe.
Post a Comment
<< Home