I am running into issues when I execute the following C# code
byte[] addr = new byte[IntPtr.Size];
IntPtr conv = (IntPtr)(BitConverter.ToInt64(addr, 0));
The error I am getting is:
System.ArgumentException: Destination array is not long enough to copy all the items in the collection. Check array index and length.
at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
at System.BitConverter.ToInt64(Byte[] value, Int32 startIndex)
I am still pretty much a noob in C# so learn as I go... Do you have an idea what I am missing here? I understand there appears to be an issue with the destination array, but not really sure why... Any guidance highly appreciated.
The underlying error here is that the source array is 4 bytes long and to read an Int64 it needs to read 8 bytes.
The oddity is that you get an error about a destination array. The method you call shouldn't be copying anything to any arrays, so why is it talking about a destination?
The error messages in the source use a mechanism where the error is identified by an id, in this case Arg_ArrayPlusOffTooSmall.
It seems reasonable to use such an id as the name of the id matches the error.
However, most of the uses of Arg_ArrayPlusOffTooSmall are when the array is used as the destination of a write rather than as the source of a read, so the error message is incorrectly made more 'helpful' by adding details which are incorrect in this case.
Congratulations, you've found a bug in .net!
Related
I am trying to read the data stored in an ICMT tag on a WAV file generated by a noise monitoring device.
The RIFF parsing code all seems to work fine, except for the fact that the ICMT tag seems to have data after the declared size. As luck would have it, it's the timestamp, which is the one absolutely critical piece of info for my application.
SYN is hex 16, which gives a size of 22, which is up to and including the NUL before the timestamp. The monitor documentation is no help; it says that the tag includes the time, but their example also has the same issue.
It is the last tag in the enclosing list, and the size of the list does include it - does that mean it doesn't need a chunk ID? I'm struggling to find decent RIFF docs, but I can't find anything that suggests that's the case; also I can't see how it'd be possible to determine that it was the last chunk and so know to read it with no chunk ID.
Alternatively, the ICMT comment chunk is the last thing in the file - is that a special case? Can I just get the time by reading everything from the end of the declared length ICMT to the end of the file and assume that will always work?
The current parser behaviour is that it's being read after the channel / dB information as a chunk ID + size, and then complaining that there was not enough data left in the file to fulfil the request.
No, it would still need its own ID. No, being the last thing in the file is no special case either. What you're showing here is malformed.
Your current parser errors correctly, as the next thing to be expected again is a 4 byte ID followed by 4 bytes for the length. The potential ID _10: is unknown and would be skipped, but interpreting 51:4 as DWORD for the length of course asks for trouble.
The device is the culprit. Do you have other INFO fields which use NULL bytes? If not then I assume the device is naive enough to consider a NULL the end of a string, despite producing himself strings with multiple NULLs.
Since I encountered countless files not sticking to standards I can only say your parser is too naive as well: it knows how long the encapsulating list is and thus could easily detect field lengths that would not fit anymore. And could ignore garbage like that. Or, in your case, offer the very specific option "add to last field".
I'm trying to create a List of byte[], from a List of BitmapImage, by getting their bytes using MemoryStream.
I put an image to let you see the debugger, which tells me that the size of my array is 1,048,576. And that is exactly what I want from my calculations:
But, now let me show you the result of the Console.WriteLine:
There are, at the end, 460 arrays of bytes, and none of them actually have the right number of bytes
And later in my code, I get an "out of range" exception
Am I doing this wrong? Why is the debugger giving me the "right" values ("right" because this is what I want) but it seems like they are wrong ?
I'm trying to read a value of type REG_RESOURCE_LIST from the registry, but without success.
The specific value I'm trying to read is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\{YourNetworkInterface}\{GUID}\Control\AllocConfig.
You can find this value by going to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI, and searching for a key that his subkey (the {GUID} part in the path) have a value named Class with a value of Net.
Or you can just search for it.
The strange thing is, when I'm opening the Control key through code, and calling GetValueNames() I'm getting the AllocConfig value name, but when calling GetValue("AllocConfig") I'm getting null (not null in reality).
Also, in ProccessMonitor, I see that when calling GetValue("AllocConfig") the result is Buffer Overflow.
Any help will be appriciated, thanks.
To get a REG_RESOURCE_LIST, you need to use RegQueryValueEx(). The value you should expect in the lpType out parameter is 8 (see here). The data you get back in the lpData out parameter is a CM_RESOURCE_LIST
Call RegQueryValueEx first to get the size of the list, allocate a buffer of that size, call ReqQueryValueEx to fill in the buffer, and cast the buffer pointer to PCM_RESOURCE_LIST. The CM_RESOURCE_LIST documentation linked above tells you how to iterate over the list and extract the contents.
http://blogs.microsoft.co.il/ischen/2007/12/04/querying-device-hardware-resources-from-the-windows-registry-using-c/
The c# project properly decodes REG_RESOURCE_LIST data structure from registry which is based on CM_RESOURCE_LIST structure that is a list that contains many CM_FULL_RESOURCE_DESCRIPTORs.
I try to save/serialize a Lua state. I know, that I had to save/serialize all globals, which I find in _G, but didn't know how to save/serialize the LuaFunctions I find. I tried to use string.dump, but that delivers only a string with the Lua signature (5 bytes with LuaQ).
The function string.dump works, because if I call
lua.DoString("print(string.len(string.dump(CountItems)))");
I get 409 instead of 5 as the length of the string. So the dump works correct. It could be a problem in LuaInterface.
Is there someone out there, how realized a serialization of a Lua state via LuaInterface?
Best regards,
Dirk
PS: I'm using KopiLua 5.1.4 with LuaInterface 2.0.4 on VS 2010 C# Express.
Solved.
The problem was, that the binary chunk, which string.dumpreturns, was handled as a string. So it was cut at the first null byte in the string, which was after 5 bytes. Changed the call of DoString, so that it handles byte arrays correct.
With the NAudio library I'm trying to mix some audio using a WaveMixerStream32 so I'm using WaveChannel32 to feed it the streams in the proper format. I've got an exception with the following message:
Offset and length were out of bounds
for the array or count is greater than
the number of elements from index to
the end of the source collection.
The minimum example I could make that also throw that error didn't include WaveMixerStream32 at all with took me to the conclusion that the problem was in how I'm using WaveChannel32. The code is this:
var audio = new WaveFileReader(OriginalAudioFileName);
var audio32 = new WaveChannel32(new WaveFileReader(OriginalAudioFileName));
WaveFileWriter.CreateWaveFile(PublicAudioFileName + "audio.wav", audio);
WaveFileWriter.CreateWaveFile(PublicAudioFileName + "audio32.wav", audio32);
audio.wav is generated just fine. audio32.wav is 58 bytes and that line thrown the exception.
What is wrong?
Yes, this is a bug in NAudio. Thanks for reporting it. I've checked in a fix (was a problem with WaveChannel32.GetSourceBuffer). You also need to know that you must set PadWithZeroes to false on your WaveChannel32 before calling WaveFileWriter.CreateWaveFile or you will create a never-ending WAV file, slowly filling up your hard disk.
I got a repro pretty easily. This looks like a basic bug in WaveChannel32.Read(), it doesn't handle .wav files with multiple channels properly. The numBytes argument looks like the size of the file, not the stream.
Let the project owner know. You'll add your issue to a rather long list though.